SDN controller interface control method and system

Abstract

A method and system for controlling the interface of an SDN controller is proposed. Aiming at the application scenario of a single App access, a control scheme of controlling access by an intermediate agent based on SGX is proposed, and a trusted control access control model is proposed in combination with the SGX technology. In the proposed model, the agent is located between the application layer and the control layer and runs in a trusted execution environment. The controller delegates the access control task to the trusted agent layer to complete, thereby realizing universal access control for heterogeneous controllers. In order to reduce the workload of the controller and securely transmit sensitive data such as policies and resources, a lightweight security protocol is designed in combination with the remote authentication and sealed storage characteristics of SGX, which includes identity authentication, key negotiation and message agent forwarding processes among the agent, App and controller. In the implementation of the protocol, the controller only needs to perform simple AES encryption. The method and system for controlling the interface of an SDN controller has low computing and network overheads and good practicality.

Description

Technical Field

[0001] The present invention relates to an SDN controller interface control method and system, which are applied to the field of software defined network (SDN). Background Art

[0002] Software-defined networking (SDN) is a new type of network architecture that has attracted attention for its flexible control and programmability. In order to reduce the possible attacks and infections between homogeneous controllers, some people have introduced the idea of ​​dynamic heterogeneous redundancy into the SDN control layer in recent years and proposed a heterogeneous SDN controller architecture. Recently, the heterogeneous SDN controller architecture has been applied to cloud data centers, Internet of Vehicles, and smart grids. Unlike traditional SDN networks, which only have apps deployed locally on the controller, more and more controller apps are deployed in the remote cloud, which puts forward new requirements for app access control. Usually, apps access network resources on the controller by calling the northbound interface (NBI) to achieve network programmability. However, the lack of encryption, authentication, and authorization management mechanisms in the northbound interface will bring many security issues, such as resource exposure and configuration tampering. To address these issues, researchers have developed specific access control systems for different controllers. However, this will have the following problems: (1) There are many different types of controllers in the heterogeneous SDN controller architecture, and the various controllers are quite different in terms of system architecture and programming language. When security requirements change, the access control systems on different controllers must be rewritten: (2) Existing systems mostly use API hooking technology to implement access control of the SDNApp inside the controller, but this method cannot implement access control of external apps that are more common in the architecture. Summary of the invention

[0003] In view of the problem that the systems in the prior art mentioned above mostly use API hooking technology to implement access control on the SDNApp inside the controller, but this method cannot implement access control of external apps that are more common in the architecture, the present invention provides an SDN controller interface control method and system, which solves the access control problem under the heterogeneous controller architecture by proposing to abstract the access control tasks and hand over the access control function to a general platform or module outside the controller.

[0004] The technical solution adopted by the present invention to solve the technical problem is: a SDN controller interface control method is as follows:

[0005] S1: The SDN controller registers and authenticates at the control layer and completes key negotiation;

[0006] S2: The control layer assigns a unique ID to the SDN controller contr , public key and private key, and store the ID locally as a key-value contr , public key and private key;

[0007] S3: The SDN controller makes a service request to the App and generates a unique hash value based on the App’s manufacturer and software version number as the App’s identity identifier ID. app , use the SDN controller private key to sign Sig sk information;

[0008] S4: The APP layer verifies the identity of the control layer and receives the sk Message, send ID to the control layer contr ||ID app ||Sig sk The message is registered, and the App verifies the identity of the control layer;

[0009] S5: The SDN controller sends a message to the intermediate proxy layer containing the identity ID, IP address, northbound interface API information, and remote access ID for logging into the controller. contr ||E k (ID contr ||IP||interface||certificate);;

[0010] S6: Encrypt the local access control policy table and send it to the control layer;

[0011] S7: The App sends the requested controller identity and the resources managed by the controller to the access control center;

[0012] S8: If the App violates the access control policy, the App will lose access rights, and the control layer will no longer request access to resources for it, and the unauthorized or illegal access behavior will be recorded in the database.

[0013] Further, S11: the SDN controller initiates a remote attestation request to the security zone of the control layer;

[0014] S12: The security zone of the control layer returns a remote attestation message to the SDN controller;

[0015] S13: After receiving the remote attestation message, the SDN controller verifies the remote attestation message and triggers the initialization phase;

[0016] S14: The SDN controller starts initialization and first generates a new random key K i , using the initial sealing key K init Encryption K i and IDcontr , generate initialization message ID contr ||E k (ID contr ||K i ), ID contr ||E k (ID contr ||K i ) message through PK PF Encrypt and send to the secure area of ​​the control layer;

[0017] S15: Control layer security zone uses SK PE Extract the ID contr , generate an ID containing K contr ||E k (ID contr ||K i ) message, and use g ab Encrypt it and send it to the application security zone;

[0018] S16: App security zone receives ID contr ||E k (ID contr ||K i ) message, it will use g ab Decrypt and extract K to initialize the key K init Mark as used and use the key ab After encryption, it returns to the control layer security zone;

[0019] S17: The control layer security zone uses the shared key g with the App security zone ab Decrypt and get K from it i , and then returns a "Success" message to the SDN controller to notify the SDN controller that the initialization has been successfully completed, including the use of K i Encrypted random number;

[0020] S18: The SDN controller decrypts the "Success" message and sets the local time. The SDN controller then returns an Ack message to the intermediate proxy security zone.

[0021] S19: The control layer security zone verifies the Ack message and sends the ID contr and the corresponding K i After being encrypted with a sealing key, it is securely stored on a local persistent hard disk.

[0022] Further, S41: the control layer queries the App registration table;

[0023] S42: If the query finds that the App has been registered, the registration is terminated; if the query finds that the App has not been registered, the registration is terminated according to the IDcontr Query the local mapping table and verify the signature sig sk Is it related to ID app If they are equal, the public key and private key are assigned to the App;

[0024] S43: The control layer stores the ID locally in key-value format contr , a mapping table of public keys and private keys.

[0025] Further, S411: the control layer security zone uses the CCA2 secure cryptographic system to generate a public key and a private key;

[0026] S412: The control layer security zone sends a remote proof message to the App security zone. The remote message contains the PK PE and the parameter g for the Diffie-Hellman key exchange a ;

[0027] S413: After receiving the remote proof, the App Security Zone will verify its legitimacy and generate another Diffie-Hellman parameter g from the remote proof. b , and send back the PK AE , g b and a remote attestation message of the current clock time;

[0028] S414: After receiving the message, the control zone security zone records the received time as the reference time and starts counting from 0. After verifying the remote proof, the proxy security zone obtains the time by calculating the reference time plus the time counter. It uses g ab Encrypt time and use SK PE Sign the ciphertext. The control security zone sends the ciphertext and signature to the App security zone;

[0029] S415: Application Security Zone PK PE Verify the signature using g ab Decrypt the ciphertext and compare the time with the local time. If all verifications are successful, the control area will be sealed. ab And return the Ack confirmation message, which is written in g ab Encrypt and use SK PE sign;

[0030] S416: After receiving the Ack message, the control layer security zone verifies the signature using PKAE and uses g ab Decrypt the ciphertext and convert g ab and PK AE The data is encrypted and securely stored using SGX's sealing key.

[0031] Furthermore, the step S5 is as follows:

[0032] S51: After the control layer receives the message, it contr Query the negotiated key;

[0033] S52: Decrypt the message to check the ID in the ciphertext message contr Is it related to the message ID? contr Whether they are consistent, whether the IP address in the decrypted ciphertext message is consistent with the IP address of the SDN controller. If they are consistent, the identity of the SDN controller is verified to be legitimate;

[0034] S53: storing the identity ID, IP address, northbound interface API information and remote access credentials of the SDN controller;

[0035] The S6 step is as follows:

[0036] S61: Control layer according to ID contr Query and decrypt to obtain the communication key;

[0037] S62: decrypt the ciphertext to verify whether the identity of the SDN controller is legitimate;

[0038] S63: Storage SDN controller access control policy contr ;

[0039] The S7 step is as follows:

[0040] S71: The control layer calls the local access control system;

[0041] S72: If the verification is successful, the access control center queries the stored mapping table based on the identity identifier, connects to the northbound interface API of the corresponding controller, enters the corresponding credentials to obtain the resources on the controller, and the agent returns the resource information to the application; if the verification is not successful, the request is rejected.

[0042] Furthermore, the SDN controller interface control system includes a negotiation module, an allocation module, a first request module, a verification module, an access module, an encryption module, a first request module and a first judgment module:

[0043] The negotiation module is used for SDN controller to register and authenticate in the control layer and complete key negotiation;

[0044] The allocation module is used by the control layer to allocate a unique ID to the SDN controller. contr , public key and private key, and store the ID locally as a key-value contr , public key and private key;

[0045] The first request module is used by the SDN controller to make a service request to the App, and generates a unique hash value based on the App's manufacturer and software version number as the App's identity identifier ID app , use the SDN controller private key to sign Sig sk information;

[0046] The verification module is used by the APP layer to verify the identity of the control layer. sk Message, send ID to the control layer contr ||ID app ||Sig sk The message is registered, and the App verifies the identity of the control layer;

[0047] The access module is used by the SDN controller to send the intermediate proxy layer containing the identity ID, IP address, northbound interface API information and remote access credentials IDcontr||Ek(IDcontr||IP||interface||certificate) for logging into the controller;

[0048] The encryption module is used to match the encrypted local access control policy table and send it to the control layer;

[0049] The first request module is used by the App to send the requested controller identity and the resources managed by the controller to the access control center;

[0050] The first judgment module is used to determine if the App violates the access control policy. The App will lose access rights, and the control layer will no longer request access to resources for it, and the unauthorized or illegal access behavior will be recorded in the database.

[0051] Further, the negotiation module includes a remote request unit, a certification unit, a first verification unit, an initialization unit, an extraction module, a receiving unit, an acquisition and transmission unit, a decryption unit and a first storage unit.

[0052] The remote request unit is used by the SDN controller to initiate a remote certification request to the security zone of the control layer;

[0053] The attestation unit is used for the security zone of the control layer to return a remote attestation message to the SDN controller;

[0054] The first verification unit is used for the SDN controller to verify the remote certification message and trigger the initialization phase after receiving the remote certification message;

[0055] The initialization unit is used to initialize the SDN controller. First, a new random key K is generated. i , using the initial sealing key K init Encryption K i and ID contr, generate initialization message ID contr ||E k (ID contr ||K i ), ID contr ||E k (ID contr ||K i ) message through PK PF Encrypt and send to the secure area of ​​the control layer;

[0056] Extraction module for control layer security zone using SK PE Extract the ID contr , generate an ID containing K contr ||E k (ID contr ||K i ) message, and use g ab Encrypt it and send it to the application security zone;

[0057] The receiving unit is used to receive the ID in the App security zone contr ||E k (ID contr ||K i ) message, it will use g ab Decrypt and extract K to initialize the key K init Mark as used and use the key ab After encryption, it returns to the control layer security zone;

[0058] Get the sending unit to use the shared key g between the control layer security zone and the App security zone ab Decrypt and get K from it i , and then returns a "Success" message to the SDN controller to notify the SDN controller that the initialization has been successfully completed, including the use of K i Encrypted random number;

[0059] The decryption unit is used by the SDN controller to decrypt the "Success" message and set the local time. The SDN controller then returns an Ack message to the intermediate proxy security zone;

[0060] The first storage unit is used to control the layer security zone to verify the Ack message, and the ID contr and the corresponding K i After being encrypted with a sealing key, it is securely stored on a local persistent hard disk.

[0061] Further, the verification module includes a query unit, an allocation unit and a second storage unit, and the query unit is used for the control layer to query the App registry;

[0062] The allocation unit is used to terminate the registration if the App is found to have been registered; if the App is found to have not been registered, the allocation unit will contr Query the local mapping table and verify the signature sig sk Is it related to ID app If they are equal, the public key and private key are assigned to the App;

[0063] The second storage unit is used to control the layer to store the ID locally in a key-value format. contr , a mapping table of public keys and private keys.

[0064] Furthermore, the specific verification of the verification module includes a generation unit, a message sending unit, a second verification unit, a third verification unit, a fourth verification unit and a third storage unit.

[0065] The generation unit is used to generate public and private keys in the control layer security zone using the CCA2 secure cryptographic system;

[0066] The message sending unit is used by the control layer security zone to send remote proof messages to the App security zone. The remote message contains the PK PE and the parameter g for the Diffie-Hellman key exchange a ;

[0067] The second verification unit is used to verify the legitimacy of the remote proof after receiving it, and generate another Diffie-Hellman parameter g from the remote proof. b , and send back the PK AE , g b and a remote attestation message of the current clock time;

[0068] The third verification unit is used to record the received time as the reference time after receiving the message, and start timing from 0. After verifying the remote proof, the proxy security zone obtains the time by calculating the reference time plus the time counter. It uses g ab Encrypt time and use SK PE Sign the ciphertext and control the security zone to send the ciphertext and signature to the App security zone;

[0069] The fourth verification unit is used for the application security zone with PK PE Verify the signature using g ab Decrypt the ciphertext and compare the time with the local time. If all verifications are successful, the control area will be sealed. ab And return the Ack confirmation message, which is written in g ab Encrypt and use SK PE sign;

[0070] The third storage unit is used to verify the signature with PKAE after receiving the Ack message and then ab Decrypt the ciphertext and convert g ab and PK AE The data is encrypted and securely stored using SGX's sealing key.

[0071] Furthermore, the access module includes a query unit, a second judgment unit and a fourth storage unit; the encryption module includes a result unit, a fifth verification unit and a fifth storage unit; the first request module includes a calling unit and an information verification unit:

[0072] The query unit is used to control the layer to receive the message according to the ID contr Query the negotiated key;

[0073] The second judgment unit is used to decrypt the message and check the ID in the ciphertext message contr Is it related to the message ID? contr Whether they are consistent, whether the IP address in the decrypted ciphertext message is consistent with the IP address of the SDN controller. If they are consistent, the identity of the SDN controller is verified to be legitimate;

[0074] The fourth storage unit is used to store the identity ID, IP address, northbound interface API information and remote access credentials for accessing the controller of the SDN controller;

[0075] The result unit is used to control the layer according to the ID contr Query and decrypt to obtain the communication key;

[0076] The fifth verification unit is used to decrypt the ciphertext to verify whether the identity of the SDN controller is legal;

[0077] The fifth storage unit is used to store the access control policy of the SDN controller. contr ;

[0078] The calling unit is used by the control layer to call the local access control system;

[0079] The information verification unit is used to query the stored mapping table according to the identity identification if the verification is passed, connect to the northbound interface API of the corresponding controller, enter the corresponding credentials to obtain the resources on the controller, and the agent returns the resource information to the application; if the verification fails, the request is rejected.

[0080] Beneficial effects of the present invention: The present invention provides an SDN controller interface control method and system, which solves the access control problem under the heterogeneous controller architecture by proposing to abstract the access control task and hand over the access control function to a general platform or module outside the controller. A general northbound interface access control scheme will be designed under the heterogeneous SDN controller architecture. Mainly through the application scenario of single App access, a control scheme for intermediate agent control access based on SGX is proposed. First, combined with SGX technology, a trusted control access control model is proposed. In the proposed model, the agent is located between the application layer and the control layer and runs in a trusted execution environment. The controller entrusts the access control task to the trusted agent layer to complete, thereby realizing universal access control for heterogeneous controllers. In order to reduce the workload of the controller and securely transmit sensitive data such as policies and resources, a lightweight security protocol is designed in combination with the remote authentication and sealed storage characteristics of SGX, which includes identity authentication, key negotiation and message agent forwarding processes among the agent, App and controller. During the implementation of the protocol, the controller only needs to perform simple AES encryption. The SDN controller interface control method and system have lower computing overhead and network overhead and better practicality. BRIEF DESCRIPTION OF THE DRAWINGS

[0081] Figure 1 It is a general flow chart of access control of the SDN controller interface control method and system provided by the present invention;

[0082] Figure 2 is a flow chart of step S1 provided by the present invention;

[0083] Figure 3 is a flow chart of S2 provided by the present invention;

[0084] Figure 4 is a flow chart of S3 provided by the present invention;

[0085] Figure 5 is a flow chart of S4 provided by the present invention;

[0086] Figure 6 is a flow chart of S5 provided by the present invention;

[0087] Figure 7 is a flow chart of S6 provided by the present invention;

[0088] Figure 8 It is a schematic diagram of the overall access control process of the SDN controller interface control method and system provided by the present invention;

[0089] Fig. 9 It is a mapping table for storing ID and the first public and private keys in a key-value manner provided by the present invention. DETAILED DESCRIPTION

[0090] In order to make the purpose, technical solution and effect of the present invention clearer and more specific, the present invention is further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0091] See also Figure 1-9 The present invention provides an SDN controller interface control method and system, an intermediate delegated control layer access control model based on a trusted execution environment. In the proposed model, a trusted execution environment (TEE) is used to implement delegate-agent access control. The delegate-agent allows various controllers to flexibly delegate access credentials and access rights of a series of SDN applications to a third party. At the same time, the SDN controller can formulate a series of rich access control policies based on time context and space context information to limit the access of App to its northbound interface. The following is the process of the SDN controller interface control method.

[0092] S1: The SDN controller registers and authenticates at the control layer, and completes key negotiation. The SDN controller registers at the control layer. The control layer will first verify whether the identity of the SDN controller is legal (such as verifying whether the IP address is legal). Similarly, the SDN controller will verify the identity of the control layer. During this process, the SDN controller and the control layer complete key negotiation. This registration uses a summary value to avoid direct transmission of passwords in the network and to avoid the problem of decoding user passwords when the authentication server is attacked by a database due to the irreversibility of the SHA256 algorithm. The hash value length used by the SHA256 algorithm is 256 bits. Since the SDN controller negotiates the public-private key pair while verifying the identity of the control layer security zone, if an attacker wants to impersonate the security zone identity and send a malicious public-private key pair to the SDN controller, it is necessary to generate a forged SGX remote attestation or guess the SGX key used in the control layer security zone.

[0093] When the SDN controller accesses the control layer security zone for the first time, it needs to register in the proxy security zone for initialization and key exchange. In the following description, the initialization of the i-th controller is taken as an example. In the attestation phase, the controller will verify its legitimacy based on the remote attestation of the control layer security zone. In the key establishment phase, a secret key is established between the controller and the proxy security zone. The controller has a sealed initialization key K, and the App security zone also knows the initialization key. The process of sharing the initialization key is completed through offline channels. The controller manufacturer obtains the serial number or certificate provided by the App manufacturer through purchase or cooperation. Both parties derive the initialization key according to the same algorithm based on the certificate. In the following process, the controller will negotiate the key K with the control layer security zone to encrypt subsequent communication messages. The process of secret key negotiation is as follows: S11: The SDN controller initiates a remote attestation request to the control layer security zone; S12: The control layer security zone returns a remote attestation message to the SDN controller; S13: After receiving the remote attestation message, the SDN controller verifies the remote attestation message and triggers the initialization phase; S14: The SDN controller starts the initialization phase. First, a new random key Ki is generated and the initialization sealed key K is used. init Encryption K i and ID contr , generate initialization message ID contr ||E k (ID contr ||K i ), where E represents the symmetric encryption algorithm, ID contr ||E k (ID contr ||K i ) message through PK PF Encrypt and send to the security zone of the control layer; S15: The security zone of the control layer uses SKPE to extract the ID contr , generate an ID containing K contr ||Ek(ID contr ||K i ) message, and use g ab Encrypt and then send it to the App Security Zone; S16: When the App Security Zone receives the ID contr| |Ek(ID contr ||K i ) message, it will use g ab Decrypt and extract K to initialize the key K init Mark it as used, and then use the key ab After encryption, it is returned to the control layer security zone; S17: the control layer security zone uses the shared key g with the App security zone ab Decrypt and get K from it i, and then returns a "Success" message to the SDN controller to notify the SDN controller that the initialization has been successfully completed, including the use of K i Encrypted random number; S18: The SDN controller decrypts the "Success" message and sets the local time. The SDN controller then returns an Ack message to the control layer security zone. The Ack message contains the encrypted random number plus 1; S19: The control layer security zone verifies the Ack message and sets the ID contr and the corresponding K i After being encrypted with a sealing key, it is securely stored on a local persistent hard disk.

[0094] S2: After completing identity authentication and key negotiation, the control layer will assign a unique identity ID to the SDN controller. contr and the first public and private keys, and store the mapping table of ID and the first public and private keys locally in key-value format, such as Fig. 9 As shown. The registered identity information includes ID U (representing the user's account ID) and the user key digest value, which is generated by the SHA256 algorithm.

[0095] S3: The SDN controller requests external App services based on its own business needs. The SDN controller can generate a unique hash value based on the App’s manufacturer software version number as the App’s identity identifier ID app , and then use your own private key to sign the message Sig sk .

[0096] S4: The APP layer verifies the identity of the control layer according to the message Sig received in S3 sk , send the message ID to the control layer contr ||ID app ||Sig sk The control layer will first query the App registration table. If the query finds that the App has been registered, the registration will be terminated. Otherwise, the ID contr Query the local mapping table and then verify the signature Sig sk Is it equal to the ID? If so, a public and private key pair is assigned to the App. The control layer stores the ID locally in key-value format. app And the mapping table of the first public and private keys.

[0097] The entities in this initialization phase are mainly the App security zone and the agent security zone. The App security zone will be initialized in the system setup program, and when the agent security zone starts working, it will interact with the control security zone to authenticate each other and share symmetric / asymmetric keys and time information. First, the App security zone and the agent security zone authenticate each other through remote authentication and use Diffie-Hellman key exchange to share secret keys. Then, the application security zone synchronizes its time with the agent security zone and confirms the shared key. The detailed process is as follows. S411: The agent security zone uses the CCA2 secure cryptographic system to generate the first public-private key pair; S412: The agent security zone sends a remote attestation message to the application security zone. This message contains PKPE and the parameter g used for Diffie-Hellman key exchange. a S413: After receiving the remote proof, the App Security Zone verifies its legitimacy. Then, it generates another Diffie-Hellman parameter g b , and send back the PK AE , g b and a remote attestation message of the current clock time.

[0098] S414: After receiving the message, the proxy security zone records the received time as the reference time and starts counting from 0. After verifying the remote proof, the proxy security zone obtains the time by calculating the reference time plus the time counter. Then, it uses g ab Encrypt the time and sign the ciphertext using SKPE. The proxy security zone sends the ciphertext and signature to the App security zone.

[0099] S415: App Security Zone PK PE Verify the signature using g ab The ciphertext is decrypted and the time is compared with the local time. If all verifications succeed, the control area is sealed. ab And return the Ack confirmation message, which is written in g ab Encrypt and use SK PE sign.

[0100] S416: After receiving the Ack message, the proxy security zone uses PK AE Verify the signature and use g ab Decrypt the ciphertext and then g ab and PK AE The data is encrypted and securely stored using SGX's sealing key.

[0101] Both the controller and the application need to perform two-way authentication on the agent, and during this process, the SGX remote authentication mechanism is needed to verify the credibility of the agent.

[0102] S5: The SDN controller sends a message to the control layer containing the identity ID, IP address, northbound interface API information, and remote access credential ID for logging into the controller. contr| |Ek(ID contr ||IP||interface||certificate), where k is the communication key negotiated in step 1. After the control layer receives the message, it will use the ID contr Query the negotiated key, decrypt the message and check the ID in the ciphertext message cont With the message header ID cont Whether they are consistent, whether the IP address in the decrypted ciphertext message is consistent with the IP address of the SDN controller. If they are consistent, verify the legality of the SDN controller, and then store the SDN controller's identity ID, IP address, northbound interface API information and remote access credentials for accessing the controller.

[0103] S6: Encrypt the local access control policy table and send it to the control layer. The SDN controller uses the key k negotiated in step 1 to encrypt the local access control policy table and send it to the control layer. The message format is ID contr ||IE k (ID contr ||policy contr ). Similar to the S5 verification process, the control layer uses the ID contr Query and decrypt to obtain the communication key, decrypt the ciphertext to verify whether the identity of the SDN controller is legal, and then store the access control policy of the SDN controller contr .

[0104] S7: App sends the requested controller identity and the resources managed by the controller to the access control center. App needs to delegate the control layer to access the resources managed by the controller. App sends the requested controller identity and the resources managed by the controller, such as switch information, topology view or controller status information, to the access control center. The control layer calls the local access control system. If it passes the verification, the access control center queries the mapping table stored in step 4 based on the identity, connects to the northbound interface API of the corresponding controller, enters the corresponding credentials to obtain the resources on the controller, and then the agent sends the resource information back to App. Otherwise, the request is rejected.

[0105] S8: If the App violates the access control policy, such as accessing other resources for longer than the specified time or unauthorized access, the App will lose access rights, and the control layer will no longer request access to resources for it, and the unauthorized or illegal access behavior will be recorded in the database.

[0106] SDN controller interface control system, the SDN controller interface control system includes a negotiation module, an allocation module, a first request module, a verification module, an access module, an encryption module, a first request module and a first judgment module. The negotiation module is used for the SDN controller to register and authenticate in the control layer and complete the key negotiation; the allocation module is used for the control layer to allocate a unique identity ID to the SDN controller contr , public key and private key, and store the ID locally as a key-value contr , public key and private key; the first request module is used by the SDN controller to make a service request to the App, and generates a unique hash value based on the App's manufacturer and software version number as the App's identity identifier ID app , use the SDN controller private key to sign Sig sk Message; the verification module is used by the APP layer to verify the identity of the control layer, according to the received Sig sk Message, send ID to the control layer contr ||ID app ||Sig sk The message is registered, and the App verifies the identity of the control layer; the access module is used by the SDN controller to send the remote access credentials IDcontr||Ek (IDcontr||IP||interface||certificate) containing the identity ID, IP address, northbound interface API information and the controller login controller to the intermediate proxy layer; the encryption module is used to match the encrypted local access control policy table and send it to the control layer; the first request module is used by the App to send the requested controller identity and the resources managed by the controller to the access control center; the first judgment module is used to if the App violates the access control policy, the App will lose access rights, and the control layer will no longer request access to resources for it, and the unauthorized or illegal access behavior will be recorded in the database.

[0107] The negotiation module includes a remote request unit, a proof unit, a first verification unit, an initialization unit, an extraction module, a receiving unit, an acquisition and transmission unit, a decryption unit, and a first storage unit. The remote request unit is used by the SDN controller to initiate a remote proof request to the security zone of the control layer; the proof unit is used by the security zone of the control layer to return a remote proof message to the SDN controller; the first verification unit is used by the SDN controller to verify the remote proof message after receiving the remote proof message and trigger the initialization phase; the initialization unit is used by the SDN controller to start initialization, and first generates a new random key K i , using the initial sealing key K init Encryption K i and ID contr , generate initialization message ID contr ||E k (ID contr||K i ), ID contr ||E k (ID contr ||K i ) message through PK PF Encrypted and sent to the security zone of the control layer; the extraction module is used in the security zone of the control layer to use SK PE Extract the ID contr , generate an ID containing K contr ||E k (ID contr ||K i ) message, and use g ab Encrypt and send it to the application security zone; the receiving unit is used to receive the ID in the App security zone contr ||E k (ID contr ||K i ) message, it will use g ab Decrypt and extract K to initialize the key K init Mark as used and use the key ab After encryption, it is returned to the control layer security zone; the sending unit is used by the control layer security zone to share the key g with the App security zone ab Decrypt and get K from it i , and then returns a "Success" message to the SDN controller to notify the SDN controller that the initialization has been successfully completed, including the use of K i The encrypted random number; the decryption unit is used by the SDN controller to decrypt the "Success" message and set the local time. The SDN controller then returns an Ack message to the intermediate proxy security zone; the first storage unit is used to control the layer security zone to verify the Ack message and send the ID contr and the corresponding K i After being encrypted with a sealing key, it is securely stored on a local persistent hard disk.

[0108] The verification module includes a query unit, a judgment unit and a second storage unit. The query unit is used by the control layer to query the App registration table; the judgment unit is used to interrupt the registration if the query finds that the App has been registered; if the query finds that the App has not been registered, then the ID is used to contr Query the local mapping table and verify the signature sig sk Is it related to ID app If they are equal, the public key and private key are assigned to the App; the second storage unit is used for the control layer to store the ID locally in a key-value format contr , a mapping table of public keys and private keys.

[0109] The specific verification of the verification module includes a generation unit, a message sending unit, a second verification unit, a third verification unit, a fourth verification unit and a third storage unit. The generation unit is used to control the layer security zone to use the CCA2 secure cryptographic system to generate public keys and private keys; the message sending unit is used to control the layer security zone to send remote proof messages to the App security zone. The remote message contains PK PE and the parameter g for the Diffie-Hellman key exchange a ; After receiving the remote proof, the App security zone will verify its legitimacy and generate another Diffie-Hellman parameter g from the remote proof b , and send back the PK AE , g b and the remote proof message of the current clock time; the third verification unit is used for receiving the message, the control zone security zone records the received time as the reference time and starts timing from 0. After verifying the remote proof, the proxy security zone obtains the time by calculating the reference time plus the time counter, which uses g ab Encrypt time and use SK PE Sign the ciphertext, control the security zone to send the ciphertext and signature to the App security zone; the fourth verification unit is used for the application security zone to use PK PE Verify the signature using g ab Decrypt the ciphertext and compare the time with the local time. If all verifications are successful, the control area will be sealed. ab And return the Ack confirmation message, which is written in g ab Encrypt and use SK PE Signature; the third storage unit is used to verify the signature with PKAE after receiving the Ack message and use g ab Decrypt the ciphertext and convert g ab and PK AE The data is encrypted and securely stored using SGX's sealing key.

[0110] The access module includes a query unit, a second judgment unit and a fourth storage unit; the encryption module includes a result unit, a fifth verification unit and a fifth storage unit; the first request module includes a call unit and an information verification unit, and the query unit is used to control the layer to receive the message according to the ID contr Query the negotiated key; the second judgment unit is used to decrypt the message and check the ID in the ciphertext message contr Is it related to the message ID? contrWhether they are consistent, whether the IP address in the decrypted ciphertext message is consistent with the IP address of the SDN controller, if they are consistent, the identity of the SDN controller is verified to be legitimate; the fourth storage unit is used to store the identity ID, IP address, northbound interface API information and remote access credentials for accessing the controller of the SDN controller; the result unit is used for the control layer to contr The query decryption obtains the communication key; the fifth verification unit is used to decrypt the ciphertext to verify whether the identity of the SDN controller is legal; the fifth storage unit is used to store the access control policy of the SDN controller contr ; The calling unit is used by the control layer to call the local access control system; the information verification unit is used to, if the verification is passed, the access control center queries the stored mapping table according to the identity identification, connects to the northbound interface API of the corresponding controller, enters the corresponding credentials to obtain the resources on the controller, and the agent returns the resource information to the application; if the verification fails, the request is rejected.

[0111] Some nouns are mentioned above. The following are the explanations of the nouns mentioned above:

[0112] key-value: The key-value distributed storage system has fast query speed, large data storage volume, and supports high concurrency. It is very suitable for querying by primary key, but cannot perform complex conditional queries.

[0113] Public key and private key: Public key and private key are a key pair obtained through encryption algorithm (i.e., a public key and a private key, that is, asymmetric encryption method). The public key can encrypt the session and verify the digital signature. Only the corresponding private key can decrypt the session data, thereby ensuring the security of data transmission. The public key is the part of the key that is open to the public, and the private key is the non-public part, which is kept by the user. The key pair obtained through the encryption algorithm can be guaranteed to be unique worldwide. When using a key pair, if one of the keys is used to encrypt a piece of data, only the other key in the key pair can be used to decrypt the data. For example: data encrypted with a public key must be decrypted with the corresponding private key; if encrypted with a private key, the corresponding public key must also be used to decrypt, otherwise it will not be successfully decrypted.

[0114] Sig sk : Digital signature.

[0115] K init : Obtain and cache Kerberos ticket-granting tickets.

[0116] PK PE : Shelf frame design.

[0117] SK PE : data table.

[0118] Success: A prompt with the message "Success".

[0119] Ack message: ACK stands for Acknowledge character, which means the received characters are error-free. The receiving station checks the received message. If no error is found, it sends a confirmation reply ACK to the sending station, indicating that the information has been received correctly and is ready to receive the next message. This control character can be sent by the central node or by a remote node. Its format depends on the adopted network protocol. When the sender receives the ACK signal, it can send the next data. If the sender does not receive the signal, the sender may resend the current data packet or stop transmitting data. The specific situation depends on the adopted network protocol.

[0120] 1. The control bit in the TCP message format consists of 6 flag bits, one of which is ACK. ACK is 1, indicating that the confirmation number is valid, and 0 indicates that the message does not contain confirmation information and the confirmation number field is ignored.

[0121] 2. ACK can also be used in the AT24cxx series of EEPROMs.

[0122] 3. In USB transmission, the ACK transaction packet is used to report the correct transmission of the packet to the host / device.

[0123] SGX: Intel SGX is actually a set of CPU instruction extensions that can create a trusted execution environment to protect code and data, which is inaccessible even to root privileges. Applications can use it to isolate specific trusted areas of code and data to prevent attacks on themselves after the underlying OS is compromised. At the same time, they do not need to trust cloud providers in software management. This is more in line with current cloud computing security issues that need to be addressed, such as storing keys for security-sensitive services.

[0124] CCA2: secure cryptographic system. CCA2 has become the standard for public key encryption. The security of CCA2 under the standard model considers the confidential communication between the two communicating parties. The sender encrypts the plaintext with the public key of the receiver, and the receiver decrypts the ciphertext with his own private key. The assumption about the adversary's ability is that the adversary can freely choose two plaintexts M0 and M1 of the same length to submit to an encryption oracle. At the same time, the adversary also has a decryption oracle. The encryption oracle randomly selects a bit b and encrypts Mb to obtain the challenge ciphertext C. The adversary can use the decryption oracle to decrypt any legal ciphertext except C. With the help of such a decryption oracle, the adversary guesses whether C is an encryption of M0 or M1. If the probability of any probabilistic polynomial time (ppt) adversary successfully guessing b is close to 12 with a negligible probability, then we call this public key encryption scheme CCA2 secure under the standard model.

[0125] Diffie-Hellman: A method to ensure that shared keys can be securely traversed through insecure networks. It is a component of OAKLEY. Whitefield and Martin Hellman proposed a wonderful key exchange protocol in 1976, called the Diffie-Hellman Key Exchange / AgreementAlgorithm. The cleverness of this mechanism is that the two parties who need to communicate securely can use this method to determine the symmetric key. Then this key can be used for encryption and decryption. But please note that this key exchange protocol / algorithm can only be used for key exchange, not for message encryption and decryption. After both parties determine the key to be used, they must use other symmetric key operation encryption algorithms to encrypt and decrypt messages.

[0126] It should be understood that the application of the present invention is not limited to the above examples. For ordinary technicians in this field, improvements or changes can be made based on the above description. All these improvements and changes should fall within the scope of protection of the claims attached to the present invention.

Claims

1. A SDN controller interface control method, characterized in that: The SDN controller interface control method comprises the following steps: S1: The SDN controller registers and authenticates at the control layer and completes key negotiation; S2: The control layer assigns a unique ID to the SDN controller contr , public key and private key, and store the ID locally as a key-value contr , public key and private key; S3: The SDN controller makes a service request to the App and generates a unique hash value based on the App’s manufacturer and software version number as the App’s identity identifier ID. app , use the SDN controller private key to sign Sig sk information; S4: The APP layer verifies the identity of the control layer and receives the sk Message, send ID to the control layer contr ||ID app ||Sig sk The message is registered, and the App verifies the identity of the control layer; S5: The SDN controller sends a message to the intermediate proxy layer containing the identity ID, IP address, northbound interface API information, and remote access credential ID for logging into the controller. contr ||E k (ID contr ||IP||interface||certificate); S6: Encrypt the local access control policy table and send it to the control layer; S7: The App sends the requested controller identity and the resources managed by the controller to the access control center; S8: If the App violates the access control policy, the App will lose access rights, and the control layer will no longer request access to resources for it, and the unauthorized or illegal access behavior will be recorded in the database; The S1 key negotiation includes: S11: The SDN controller initiates a remote attestation request to the security zone of the control layer; S12: The security zone of the control layer returns a remote attestation message to the SDN controller; S13: After receiving the remote attestation message, the SDN controller verifies the remote attestation message and triggers the initialization phase; S14: The SDN controller starts initialization and first generates a new random key K i , using the initialization key K init Encryption K i and ID contr , generate initialization message ID contr ||E k (ID contr ||K i ), ID contr ||E k (ID contr ||K i ) Message through PK PF Encrypt and send to the secure area of ​​the control layer; S15: Control layer security zone uses SK PE Extract the ID contr , generate an ID containing K contr ||E k (ID contr ||K i ) message, and use g ab Encrypt and send it to the application security zone, where K is the communication key; S16: App security zone receives ID contr ||E k (ID contr ||K i ) message, it will use g ab Decrypt and extract K to initialize the key K init Mark as used and use the key ab After encryption, it returns to the control layer security zone; S17: The control layer security zone uses the shared key g with the App security zone ab Decrypt and get K from it i , and then returns a "Success" message to the SDN controller, notifying the SDN controller that initialization has been successfully completed, including the use of K i Encrypted random number; S18: The SDN controller decrypts the "Success" message and sets the local time. The SDN controller then returns an Ack message to the intermediate proxy security zone. S19: The control layer security zone verifies the Ack message and sends the ID contr and the corresponding K i After being encrypted with a sealing key, it is securely stored on a local persistent hard disk; The verification step of S4 further includes: S411: The control layer security zone uses the CCA2 secure cryptographic system to generate public and private keys; S412: The control layer security zone sends a remote proof message to the App security zone. The remote message contains the PK PE and the parameter g for the Diffie-Hellman key exchange a ; S413: After receiving the remote proof, the App Security Zone will verify its legitimacy and generate another Diffie-Hellman parameter g from the remote proof. b , and send back the PK AE , g b and the current clock time of the remote message proof, the g b A key parameter for a method of ensuring that a shared KEY securely traverses an insecure network, wherein Diffie-Hellman is a component of OAKLEY, called the Diffie-Hellman key exchange protocol / algorithm; S414: After receiving the message, the control zone security zone records the received time as the reference time and starts counting from 0. After verifying the remote proof, the proxy security zone obtains the time by calculating the reference time plus the time counter. It uses g ab Encrypt time and use SK PE Sign the ciphertext and control the security zone to send the ciphertext and signature to the App security zone; S415: Application Security Zone PK PE Verify the signature using g ab Decrypt the ciphertext and compare the time with the local time; if all verifications are successful, the control area will be sealed. ab And return an Ack confirmation message, which is written in g ab Encrypt and use SK PE sign; S416: After receiving the Ack message, the control layer security zone verifies the signature using PKAE and uses g ab Decrypt the ciphertext and convert g ab and PK AE The data is encrypted and securely stored using SGX's sealing key.

2. The SDN controller interface control method according to claim 1, characterized in that: The S4 comprises the following steps: S41: The control layer queries the App registry; S42: If the query finds that the App has been registered, the registration is terminated; if the query finds that the App has not been registered, the registration is terminated according to the ID contr Query the local mapping table and verify the signature sig sk Is it related to ID app If they are equal, the public key and private key are assigned to the App; S43: The control layer stores the ID locally in key-value format contr , a mapping table of public keys and private keys.

3. The SDN controller interface control method according to claim 1, characterized in that: The S5 step is as follows: S51: After the control layer receives the message, it contr Query the negotiated key; S52: Decrypt the message to check the ID in the ciphertext message contr Is it related to the message ID? contr Whether they are consistent, whether the IP address in the decrypted ciphertext message is consistent with the IP address of the SDN controller. If they are consistent, the identity of the SDN controller is verified to be legitimate; S53: storing the identity ID, IP address, northbound interface API information and remote access credentials of the SDN controller; The S6 step is as follows: S61: Control layer according to ID contr Query and decrypt to obtain the communication key; S62: decrypt the ciphertext to verify whether the identity of the SDN controller is legitimate; S63: Storage SDN controller access control policy contr ; The S7 step is as follows: S71: The control layer calls the local access control system; S72: If the verification is successful, the access control center queries the stored mapping table based on the identity identifier, connects to the northbound interface API of the corresponding controller, enters the corresponding credentials to obtain the resources on the controller, and the agent returns the resource information to the application; if the verification is not successful, the request is rejected.

4. An SDN controller interface control system, characterized in that: The SDN controller interface control system includes a negotiation module, an allocation module, a first request module, a verification module, an access module, an encryption module, a first request module and a first judgment module; The negotiation module is used for SDN controller to register and authenticate in the control layer and complete key negotiation; The allocation module is used by the control layer to assign a unique ID to the SDN controller. contr , public key and private key, and store the ID locally as a key-value contr , public key and private key; The first request module is used by the SDN controller to make a service request to the App, and generates a unique hash value based on the App's manufacturer and software version number as the App's identity identifier ID app , use the SDN controller private key to sign Sig sk information; The verification module is used by the APP layer to verify the identity of the control layer. sk Message, send ID to the control layer contr ||ID app ||Sig sk The message is registered, and the App verifies the identity of the control layer; The access module is used by the SDN controller to send the identity ID, IP address, northbound interface API information and remote access credential ID to the intermediate proxy layer. contr ||E k (ID contr ||IP||interface||certificate); The encryption module is used to match the encrypted local access control policy table and send it to the control layer; The first request module is used for the App to send the requested controller identity and the resources managed by the controller to the access control center; The first judgment module is used to determine if the App violates the access control policy. The App will lose access rights, and the control layer will no longer request access to resources for it, and the unauthorized or illegal access behavior will be recorded in the database. The negotiation module includes a remote request unit, a certification unit, a first verification unit, an initialization unit, an extraction module, a receiving unit, an acquisition and transmission unit, a decryption unit and a first storage unit; The remote request unit is used by the SDN controller to initiate a remote certification request to the security zone of the control layer; The attestation unit is used for the security zone of the control layer to return a remote attestation message to the SDN controller; The first verification unit is used for the SDN controller to verify the remote certification message and trigger the initialization phase after receiving the remote certification message; The initialization unit is used to initialize the SDN controller. First, a new random key K is generated. i , using the initialization key K init Encryption K i and ID contr , generate initialization message ID contr ||E k (ID contr ||K i ), ID contr ||E k (IDcontr||K i ) Message through PK PF Encrypt and send to the secure area of ​​the control layer; Extraction module for control layer security zone using SK PE Extract the ID contr , generate an ID containing K contr ||E k (ID contr ||K i ) message, and use g ab Encrypt it and send it to the application security zone; The receiving unit is used to receive the ID in the App security zone contr ||E k (ID contr ||K i ) message, it will use g ab Decrypt and extract K to initialize the key K init Mark as used and use the key ab After encryption, it is returned to the control layer security zone; the sending unit is used by the control layer security zone to share the key g with the App security zone ab Decrypt and get K from it i , and then returns a "Success" message to the SDN controller, notifying the SDN controller that initialization has been successfully completed, including the use of K i Encrypted random number; The decryption unit is used by the SDN controller to decrypt the "Success" message and set the local time. The SDN controller then returns an Ack message to the intermediate proxy security zone; The first storage unit is used to control the layer security zone to verify the Ack message, and the ID contr and the corresponding K i After being encrypted with a sealing key, it is securely stored on a local persistent hard disk; The verification module includes a query unit, an allocation unit and a second storage unit; The query unit is used by the control layer to query the App registry; The allocation unit is used to terminate the registration if the App is found to have been registered; if the App is found to have not been registered, the allocation unit will contr Query the local mapping table and verify the signature sig sk Is it related to ID app If they are equal, the public key and private key are assigned to the App; The second storage unit is used to control the layer to store the ID locally in a key-value format. contr , a mapping table of public keys and private keys; The specific verification of the verification module includes a generation unit, a message sending unit, a second verification unit, a third verification unit, a fourth verification unit and a third storage unit; The generation unit is used to generate public and private keys in the control layer security zone using the CCA2 secure cryptographic system; The message sending unit is used by the control layer security zone to send remote proof messages to the App security zone. The remote message contains the PK PE and the parameter g for the Diffie-Hellman key exchange a ; The second verification unit is used to verify the legitimacy of the remote proof after receiving it, and generate another Diffie-Hellman parameter g from the remote proof. b , and send back the PK AE , g b and a remote attestation message of the current clock time; The third verification unit is used to record the received time as the reference time after receiving the message, and start timing from 0. After verifying the remote proof, the proxy security zone obtains the time by calculating the reference time plus the time counter. It uses g ab Encrypt time and use SK PE Sign the ciphertext and control the security zone to send the ciphertext and signature to the App security zone; The fourth verification unit is used for the application security zone with PK PE Verify the signature using g ab Decrypt the ciphertext and compare the time with the local time. If all verifications are successful, the control area will be sealed. ab And return an Ack confirmation message, which is written in g ab Encrypt and use SK PE sign; The third storage unit is used to verify the signature with PKAE after receiving the Ack message and then ab Decrypt the ciphertext and convert g ab and PK AE The data is encrypted and securely stored using SGX's sealing key.

5. The SDN controller interface control system according to claim 4, characterized in that: The access module includes a query unit, a second judgment unit and a fourth storage unit; the encryption module includes a result unit, a fifth verification unit and a fifth storage unit; the first request module includes a calling unit and an information verification unit; The query unit is used to control the layer to receive the message according to the ID contr Query the negotiated key; The second judgment unit is used to decrypt the message and check the ID in the ciphertext message contr Is it related to the message ID? contr Whether they are consistent, whether the IP address in the decrypted ciphertext message is consistent with the IP address of the SDN controller. If they are consistent, the identity of the SDN controller is verified to be legitimate; The fourth storage unit is used to store the identity ID, IP address, northbound interface API information and remote access credentials for accessing the controller of the SDN controller; The result unit is used to control the layer according to the ID contr Query and decrypt to obtain the communication key; The fifth verification unit is used to decrypt the ciphertext to verify whether the identity of the SDN controller is legal; The fifth storage unit is used to store the access control policy of the SDN controller. contr ; The calling unit is used by the control layer to call the local access control system; The information verification unit is used to query the stored mapping table according to the identity identification if the verification is passed, connect to the northbound interface API of the corresponding controller, enter the corresponding credentials to obtain the resources on the controller, and the agent returns the resource information to the application; if the verification fails, the request is rejected.

Images