Implementation method of self-organized encrypted tunnel in Ethernet link using quantum key distribution

Abstract

The present invention discloses a method for implementing a self-organizing encryption tunnel over an Ethernet link using quantum key distribution. The method is applied to a transmitting-end encryption bridge and includes: sending a policy negotiation frame to a second encryption bridge, the policy negotiation frame including multiple negotiation policies, each negotiation policy containing the source MAC address and session key component of a corresponding encryption policy subtable; the second encryption bridge serving as a receiving-end encryption bridge; searching a local encryption policy table for a corresponding encryption policy subtable based on the source MAC address of an outbound Ethernet data frame; searching the corresponding encryption policy item in the corresponding encryption policy subtable based on the destination MAC address of the outbound Ethernet data frame; encrypting and encapsulating the Ethernet data frame based on the corresponding encryption policy item to obtain an encrypted Ethernet frame, which is then sent to the second encryption bridge. The present invention implements a highly secure and reliable IP-free Layer 2 secure channel.

Description

Technical Field

[0001] The present invention relates to the technical field of cryptographic applications, and in particular to a method for realizing a self-organized encryption tunnel of an Ethernet link using quantum key distribution. Background Art

[0002] IEEE802.1AE-Media Access Control (MAC) Security defines a MAC layer security standard that protects the confidentiality and integrity of Ethernet message frames by inserting security tags into Ethernet packets and performing symmetric encryption and integrity check (ICV) on Ethernet message frames other than MAC addresses, and provides a certain degree of resistance to replay attacks. The MACsec Key Agreement protocol (MKA) in IEEE802.1X-Port-Based Network Access Control defines the method for physical key negotiation in Ethernet networks, which is used to establish 802.1AE MACsec encryption and integrity protection keys. These two sets of protocols combine to form the IEEE security solution at the Ethernet MAC layer. However, in actual use, the deployment and implementation of these two sets of protocols are not widespread, and the following problems exist:

[0003] (1) The encapsulation format and frame processing process of Ethernet frames are relatively complex, the process definition of policy management is not clear enough, the feasibility is poor, and the efficiency is low.

[0004] (2) The key used to encrypt Ethernet message frames is allocated to the entity that implements the MACsec protocol, rather than to each source entity with a MAC address. Multiple sources share one Ethernet frame protection key, and this key is only related to the entity that implements the MACsec protocol.

[0005] (3) MKA shares a symmetric key within a group to protect the negotiation process. The key can only be updated after a period of use, and there is a certain degree of repetitiveness in its use.

[0006] (4) MACsec does not support framing. When the frame length exceeds the MTU due to a long security tag and ICV, frame loss will occur.

[0007] In related technology, Chinese invention patent application publication number CN110752979A describes a method, apparatus, and network device for tunneling message transmission. The method includes: upon receiving a message from a user-side network interface, determining the service tunnel and next hop corresponding to the message; determining the message's encapsulation format based on the network type between the user and the next hop; encapsulating the message according to the encapsulation format to obtain a tunnel protocol message; and sending the tunnel protocol message to the destination aggregation device via the corresponding service tunnel. In this solution, message transmission is no longer restricted by network type.

[0008] This solution describes a routing and tunneling technology in the data forwarding process, and does not involve tunnel encapsulation, encryption and decryption, and key distribution.

[0009] Chinese invention patent application publication number CN106341404A describes an IPSec VPN system based on a many-core processor. The system includes an encryption system and a decryption system, including a packet receiving module, a rate limiting module, an ingress firewall module, an IPSec policy retrieval module, an IPSec encapsulation module, an encryption module, a decryption module, an egress firewall, a decapsulation module, an Ethernet header addition module, a re-encapsulation module, an IP packet forwarding module, and a packet sending module. This solution enables secure transmission of high-speed network traffic. It uses the IPSec protocol at the IP network layer for tunnel encapsulation and key distribution, rather than Ethernet frame-based tunnel encapsulation and key distribution.

[0010] However, the above solution is not applicable to the application scenario of Layer 2 Ethernet frame security encapsulation and encryption, which does not have IP addresses and cannot distribute keys and establish secure tunnels through conventional methods. Summary of the Invention

[0011] The technical problem to be solved by the present invention is how to realize a highly secure, lightweight and efficient Ethernet data frame encryption tunnel transmission method to solve the security problem of non-IP layer 2 Ethernet data frames.

[0012] The present invention solves the above technical problems through the following technical means:

[0013] In a first aspect, the present invention proposes a method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution, which is applied to a sending-end encryption bridge. The method comprises:

[0014] Sending a policy negotiation frame to the second encryption bridge, wherein the policy negotiation frame includes a plurality of negotiation policies, and the content of each negotiation policy is a source MAC address and a session key component of a corresponding encryption policy subtable;

[0015] For the source MAC address of the outgoing Ethernet data frame, the corresponding encryption policy sub-table is searched from the local encryption policy table;

[0016] Search the corresponding encryption policy item from the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame;

[0017] The Ethernet data frame is encrypted and encapsulated according to the corresponding encryption policy item to obtain an encrypted Ethernet frame and send it to the second encryption bridge.

[0018] The present invention utilizes the MAC automatic learning of the encryption bridge port, combined with the point-to-multipoint policy distribution method of multicast, to realize the automatic exchange of network parameters and security parameters between members in the security domain, and on this basis realizes the automatic generation of security policies and session keys, thereby safely and efficiently solving the security policy distribution and management problems of Layer 2 Ethernet devices without IP addresses; and by adopting the encrypted tunnel encapsulation method of the internal and external MAC addresses in the Layer 2 Ethernet link, a highly secure and reliable Layer 2 security channel without IP addresses is realized.

[0019] In a second aspect, the present invention proposes a method for implementing a self-organized decryption tunnel in an Ethernet link using quantum key distribution, which is applied to a receiving-end encryption bridge. The method comprises:

[0020] receiving a policy negotiation frame sent by a first encryption bridge, where the first encryption bridge and the receiving-end encryption bridge are in the same security domain;

[0021] Based on each negotiation policy in the policy negotiation frame, refreshing each encryption policy sub-table in its local encryption policy table and each decryption policy sub-table in its local decryption policy table;

[0022] receiving an encrypted Ethernet frame sent by the first encryption bridge, where the encrypted Ethernet frame is obtained by the sending-end encryption bridge encrypting and encapsulating an outbound Ethernet data frame based on its locally corresponding encryption policy item;

[0023] According to the source MAC address of the encrypted Ethernet frame, the corresponding decryption policy subtable is searched from its local decryption policy table, the corresponding decryption policy item is searched based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and the encrypted Ethernet frame is decrypted and decapsulated according to the corresponding decryption policy item to obtain the Ethernet data frame.

[0024] In a third aspect, the present invention proposes a method for implementing a self-organized encryption and decryption tunnel of an Ethernet link using quantum key distribution, wherein the second encryption bridge is a member of the security domain of the first encryption bridge, and the method comprises:

[0025] The first encryption bridge sends a policy negotiation frame to the second encryption bridge, wherein the policy negotiation frame includes a plurality of negotiation policies, and the content of each negotiation policy is a source MAC address and a session key component of a corresponding encryption policy subtable;

[0026] The second encryption network bridge receives the policy negotiation frame, and based on each negotiation policy in the policy negotiation frame, refreshes each encryption policy sub-table in the encryption policy table and each decryption policy sub-table in the decryption policy table of the second encryption network bridge;

[0027] The first encryption bridge searches a local encryption policy table for a corresponding encryption policy subtable according to the source MAC address of the outbound Ethernet data frame, searches the corresponding encryption policy item in the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame, encrypts and encapsulates the Ethernet data frame according to the corresponding encryption policy item, obtains an encrypted Ethernet frame, and sends it to the second encryption bridge;

[0028] The second encryption bridge receives the encrypted Ethernet frame, searches for the corresponding decryption policy subtable from the local decryption policy table according to the source MAC address of the encrypted Ethernet frame, searches for the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypts and decapsulates the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame.

[0029] In a fourth aspect, the present invention provides an encryption bridge, which serves as a sending end and includes:

[0030] a policy negotiation frame sending module, configured to send a policy negotiation frame to the second encryption bridge, wherein the policy negotiation frame includes a plurality of negotiation policies, each negotiation policy including a source MAC address and a session key component of a corresponding encryption policy subtable, and the second encryption bridge serves as a receiving end encryption bridge;

[0031] A first search module is used to search the corresponding encryption policy sub-table from the local encryption policy table for the source MAC address of the outbound Ethernet data frame;

[0032] A second search module is used to search the corresponding encryption policy item from the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame;

[0033] The encryption and encapsulation module is used to encrypt and encapsulate the Ethernet data frame according to the corresponding encryption policy item, obtain the encrypted Ethernet frame and send it to the second encryption bridge.

[0034] In a fifth aspect, the present invention provides an encryption bridge, which serves as a receiving end and includes:

[0035] A policy negotiation frame receiving module, configured to receive a policy negotiation frame sent by a first encryption bridge, wherein the first encryption bridge and the receiving end encryption bridge are in the same security domain;

[0036] A policy refresh module, configured to refresh each encryption policy sub-table in its local encryption policy table and each decryption policy sub-table in its decryption policy table based on each negotiation policy in the policy negotiation frame;

[0037] An encrypted Ethernet frame receiving module is used to receive the encrypted Ethernet frame sent by the first encryption bridge, where the encrypted Ethernet frame is obtained by the sending end encryption bridge encrypting and encapsulating the outbound Ethernet data frame based on its local corresponding encryption policy item;

[0038] The decryption and decapsulation module is used to search the corresponding decryption policy subtable from its local decryption policy table according to the source MAC address of the encrypted Ethernet frame, search the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypt and decapsulate the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame.

[0039] In a sixth aspect, the present invention proposes a system for implementing self-organized encryption and decryption tunnels on Ethernet links using quantum key distribution. The system includes a first encryption bridge, a second encryption bridge, a quantum key distribution system, and a management and control platform. The first encryption bridge and the second encryption bridge are connected, and the first encryption bridge and the second encryption bridge are both connected to the management and control platform. The first encryption bridge, the second encryption bridge, and the management and control platform are respectively connected to the quantum key distribution system, wherein:

[0040] The management and control platform is used to provide the correspondence between the first encryption bridge, the second encryption bridge, the key agent, and the quantum network node, perform security domain division, and provide encryption bridge registration and identity binding services;

[0041] The quantum key distribution system is used to provide agent functions for master key injection and online master key distribution;

[0042] The first encryption bridge is configured to send a policy negotiation frame to the second encryption bridge, wherein the policy negotiation frame includes a plurality of negotiation policies, and the content of each negotiation policy is a source MAC address and a session key component of a corresponding encryption policy subtable;

[0043] After receiving the policy negotiation frame, the second encryption bridge is configured to refresh each encryption policy sub-table in the local encryption policy table of the second encryption bridge and each decryption policy sub-table in the decryption policy table based on each negotiation policy in the policy negotiation frame;

[0044] The first encryption bridge is configured to search a corresponding encryption policy subtable in a local encryption policy table according to the source MAC address of the outbound Ethernet data frame, search a corresponding encryption policy item in the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame, and encrypt and encapsulate the Ethernet data frame according to the corresponding encryption policy item to obtain an encrypted Ethernet frame and send it to the second encryption bridge;

[0045] After the second encryption bridge receives the encrypted Ethernet frame, it is used to search the corresponding decryption policy subtable from the local decryption policy table according to the source MAC address of the encrypted Ethernet frame, search the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypt and decapsulate the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame.

[0046] The advantages of the present invention are:

[0047] (1) The present invention utilizes the automatic MAC learning of the encryption bridge port, combined with the point-to-multipoint policy distribution method of multicast, to realize the automatic exchange of network parameters and security parameters between members in the security domain, and on this basis realizes the automatic generation of security policies and session keys, thereby safely and efficiently solving the security policy distribution and management problems of Layer 2 Ethernet devices without IP addresses; and by adopting the encrypted tunnel encapsulation method of the inner and outer MAC addresses in the Layer 2 Ethernet link, a highly secure and reliable Layer 2 security channel without IP is realized.

[0048] (2) Through a simple and efficient frame segmentation and merging processing method, as well as the switching between the primary and backup keys, reliable transmission with zero frame loss in the encrypted tunnel is achieved without affecting the Layer 2 network services.

[0049] (3) Through peer-to-peer negotiation of session keys, combined with a simple and efficient index generation method and a relatively reasonable and efficient Ethernet tunnel encapsulation format design and processing flow, a lightweight, highly secure, and highly reliable IP-free Layer 2 Ethernet security channel is achieved.

[0050] (4) By dividing the security domain and pre-filling a large number of identical master keys for each device node in the security domain and using them randomly, the problem of identity authentication and distribution of session keys between bridge device nodes with encryption intercommunication requirements is solved safely and efficiently.

[0051] Additional aspects and advantages of the present invention will be set forth in part in the description which follows and, in part, will be obvious from the description which follows, or may be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 11 is a flow chart of a method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution, as proposed in the first embodiment of the present invention;

[0053] Figure 2 2 is a flow chart of a method for implementing a self-organized decryption tunnel over an Ethernet link using quantum key distribution, as proposed in the second embodiment of the present invention;

[0054] Figure 3 1 is a flow chart of a method for implementing a self-organized encryption and decryption tunnel over an Ethernet link using quantum key distribution, as proposed in the third embodiment of the present invention;

[0055] Figure 4 This is a schematic diagram of the strategy table structure in the third embodiment of the present invention;

[0056] Figure 5 Schematic diagram of the structure of the encryption bridge proposed in the fourth embodiment of the present invention;

[0057] Figure 6 is a schematic diagram of the structure of the encryption bridge proposed in the fifth embodiment of the present invention;

[0058] Figure 7 2 is a schematic diagram of the structure of a system for implementing a self-organizing encryption and decryption tunnel over an Ethernet link using quantum key distribution, as proposed in a sixth embodiment of the present invention;

[0059] Figure 8 2 is a schematic diagram of the structure of an encryption bridge according to a sixth embodiment of the present invention;

[0060] Figure 9 1. It is a schematic diagram of the working process of the Ethernet link self-organizing encryption and decryption tunnel implementation system using quantum key distribution in the sixth embodiment of the present invention. DETAILED DESCRIPTION

[0061] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0062] Example 1

[0063] like Figure 1 As shown, the first embodiment of the present invention proposes a method for implementing a self-organized encryption tunnel of an Ethernet link using quantum key distribution, which is applied to a sending-end encryption bridge. The method includes the following steps:

[0064] S101: Send a policy negotiation frame to the second encryption bridge, where the policy negotiation frame includes multiple negotiation policies, each negotiation policy containing a source MAC address and a session key component of a corresponding encryption policy subtable. The second encryption bridge serves as a receiving encryption bridge.

[0065] It should be noted that the second encryption bridge is a member of the security domain to which the sending-end encryption bridge belongs. Both the sending-end encryption bridge and the second encryption bridge send registration requests and identity binding service requests to the management and control platform in advance. After all encryption bridges complete the registration and identity binding services, the management and control platform will define the security domain.

[0066] It's important to note that when each encryption bridge starts up, it constructs a local encryption policy table based on the MAC learning mechanism of a typical bridge. This encryption policy table consists of multiple encryption policy subtables. Each encryption policy subtable is represented by a unique MAC address, corresponding to the source MAC address of Ethernet frames received by the encryption port of this bridge. This MAC address is called the subtable source MAC. Different encryption policy subtables have different subtable source MACs. Each encryption policy subtable contains two uniquely numbered session keys. The session key component is a random number periodically collected and updated from the encryption bridge's built-in random number generator.

[0067] In this embodiment, in the encryption policy table initially established by each encryption bridge, each encryption policy sub-table only contains the sub-table source MAC address corresponding to the encryption policy sub-table and the session key components with different numbers. Then, policy negotiation frames are periodically sent to members within the same security domain to implement refresh management of the local encryption policy tables of members within the security domain. By utilizing the MAC automatic learning of the bridge port and combining the point-to-multipoint policy distribution method of multicast, the automatic exchange of network parameters and security parameters between members within the security domain is realized.

[0068] S102. Search the local encryption policy table for the corresponding encryption policy sub-table for the source MAC address of the outbound Ethernet data frame;

[0069] It should be noted that the unique MAC address of each encryption policy sub-table in the encryption policy table corresponds to a source MAC address of the received Ethernet frame. Therefore, based on the source MAC address of the outbound Ethernet data frame, the corresponding encryption policy sub-table can be found from the local encryption policy table.

[0070] S103, searching the corresponding encryption policy item from the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame;

[0071] Specifically, each encryption policy sub-table includes multiple encryption policy items, and the encryption policy items include destination MAC address information. The corresponding encryption policy item can be found from the corresponding encryption policy sub-table according to the destination MAC address information of the outbound Ethernet data frame.

[0072] S104: Encrypt and encapsulate the Ethernet data frame according to the corresponding encryption policy item to obtain an encrypted Ethernet frame and send it to the second encryption bridge.

[0073] This embodiment proposes a complete set of protocol specifications for tunnel encapsulation and key distribution based on Ethernet frames, and realizes the generation and distribution of encryption policies and keys in a self-organizing manner without a center and IP. It utilizes the automatic MAC learning of the encryption bridge port, combined with the point-to-multipoint policy distribution method of multicast, to realize the automatic exchange of network parameters and security parameters between members in the security domain. On this basis, it realizes the automatic generation of security policies and session keys, and safely and efficiently solves the security policy distribution and management problems of Layer 2 Ethernet devices without IP addresses. In addition, by adopting the encrypted tunnel encapsulation method of internal and external MAC addresses in the Layer 2 Ethernet link, a highly secure and reliable IP-free Layer 2 security channel is realized.

[0074] In one embodiment, before the step S101: sending the policy negotiation frame to the second encryption bridge, the method further includes the steps of:

[0075] When the sending end encryption bridge is started, a local encryption policy table is established, wherein the encryption policy table includes a plurality of encryption policy sub-tables, the MAC address of each encryption policy sub-table corresponds to a source MAC address of an Ethernet data frame received by the encryption port of the sending end encryption bridge, and each encryption policy sub-table in the initially established encryption policy table includes the MAC address of each encryption policy sub-table and a session key component;

[0076] Based on the local encryption policy table, a corresponding decryption policy table is established, and the decryption policy table includes multiple decryption policy sub-tables. The MAC address of each decryption policy sub-table corresponds to a source MAC address of the Ethernet data frame received by the open port of this encryption bridge. Each decryption policy sub-table in the initially established decryption policy table includes the MAC address of each decryption policy sub-table.

[0077] It should be noted that this encryption bridge uses the corresponding encryption policy items in the encryption policy table to encrypt and encapsulate outgoing Ethernet data frames, and uses the corresponding decryption policy items in the decryption policy table to decrypt and decapsulate received encrypted Ethernet data frames.

[0078] It should be noted that the encryption policy table and decryption policy table initially established by the encryption bridge are managed through policy negotiation frames sent by other members in the same security domain, realizing the automatic exchange of network parameters and security parameters between members in the security domain, and on this basis realizing the automatic generation of security policies and session keys.

[0079] In one embodiment, when the encryption policy table is established, each encryption policy sub-table therein only contains the sub-table source MAC address and the session key component, and the addition or update of its table entries comes from the key negotiation frame; when the decryption policy table is established, each decryption policy sub-table only contains the sub-table source MAC address, and the addition or update of its table entries comes from the key negotiation frame and the table entries of the encryption policy sub-table.

[0080] Specifically, each encryption policy entry in the encryption policy subtable includes the destination MAC address, the destination MAC number (2 bytes), the encapsulated source MAC address, the encapsulated destination MAC address, the number of the currently used session key, different numbered session keys, and the initialization vector and key usage count corresponding to the session key;

[0081] Each decryption policy item in the decryption policy subtable includes a decryption index, a destination MAC address, an original source MAC address, an original destination MAC address, session keys of different numbers, an initialization vector corresponding to the session key, and a key usage count.

[0082] Among them, the session keys are numbered 0 and 1 respectively, and the relevant data of each numbered session key includes the initialization vector and the key usage count; the destination MAC number in the encryption policy item comes from the source MAC number of the key negotiation frame sent by other encryption network bridges in the same security domain, and is not uniformly numbered in the local encryption policy subtable of this encryption bridge; and the source MAC address in the key negotiation frame comes from the encryption policy subtable number of the encryption bridge that sends the key negotiation frame, that is, it is the same source MAC address as the encryption policy subtable.

[0083] Among them, a decryption policy table is established based on the encryption policy table. The table consists of multiple decryption policy sub-tables. Each decryption policy sub-table is represented by a unique MAC address. The MAC address corresponds to a source MAC address of the Ethernet frame received by the bright port of this bridge (corresponding to the encapsulation destination MAC in the encryption policy item), which is called the sub-table source MAC. Different decryption policy sub-tables have different sub-table source MACs.

[0084] The decryption policy subtable consists of multiple decryption policy items. Each decryption policy item includes a 4-byte decryption index, destination MAC address, original (before encapsulation) source MAC address, original (before encapsulation) destination MAC address, two session keys numbered 0 and 1, the initialization vector of the session key, and the key usage count.

[0085] In one embodiment, the source MAC address of each decryption policy sub-table in the decryption policy table is the encapsulated destination MAC address of each encryption policy sub-table in the corresponding encryption policy table; the destination MAC address, original source MAC address, original destination MAC address, session keys with different numbers and initialization vectors corresponding to the session keys and key usage counts in the decryption policy items in the decryption policy sub-table are from all the encapsulated source MAC addresses, destination MAC addresses, source MAC addresses corresponding to the encryption policy sub-tables, session keys with different numbers and initialization vectors corresponding to the session keys and key usage counts in the encryption policy items of each encryption policy sub-table whose source MAC addresses are the corresponding source MAC addresses of this decryption policy sub-table; the 4-byte decryption index value in the decryption policy item is composed of the 2-byte encryption policy sub-table number and the 2-byte destination MAC number of the corresponding encryption policy item.

[0086] In one embodiment, the step S101 of sending a policy negotiation frame to the second encryption bridge includes the following steps:

[0087] Generate the policy negotiation frame according to each encryption policy sub-table in the local encryption policy table and its source MAC address;

[0088] Randomly selecting a master key from the first secure storage medium, encrypting the portion of the policy negotiation frame excluding the frame header using the master key, calculating a check value of the policy negotiation frame using a keyed hash algorithm, obtaining the encrypted policy negotiation frame, and sending the encrypted policy negotiation frame to the second encryption bridge;

[0089] The first secure storage medium is integrated into the sending end encryption bridge, and the format of the encrypted policy negotiation frame is:

[0090] 14-byte Ethernet frame header (source MAC + destination MAC + frame type) + 1-byte frame policy count + 4-byte master key ID + k*(subtable number + subtable source MAC + n-byte subtable session key component 0 + n-byte subtable session key component 1) + ICV (first integrity check value), where k represents the number of policies contained in this frame.

[0091] In this embodiment, the encryption bridge periodically sends policy negotiation frames to members within the security domain. Each policy negotiation frame consists of multiple negotiation policies. Each policy corresponds to an encryption policy subtable and its source MAC address for the encryption bridge, and its contents are the source MAC address and session key components of that subtable. The entire Ethernet frame is encrypted using a master key randomly selected from a first secure storage medium (the Ethernet frame header is not encrypted), and a first integrity check value (including the frame header) is calculated using a keyed hashing algorithm (HMAC).

[0092] It should be noted that the master key stored in the first secure storage medium is pre-filled with the quantum key distribution system, and each encryption bridge device node in the security domain is pre-filled with a large number of identical master keys and used randomly, which can safely and efficiently solve the problem of identity authentication and distribution of session keys between bridge device nodes with encryption intercommunication requirements.

[0093] In one embodiment, the step S101 of sending the encrypted policy negotiation frame to the second encryption bridge includes the following steps:

[0094] Determining whether the length of the encrypted policy negotiation frame exceeds the MTU of the sending interface;

[0095] If yes, dividing the encrypted policy negotiation frame into multiple frames and sending them to the second encryption bridge;

[0096] If not, directly sending the encrypted policy negotiation frame to the second encryption bridge;

[0097] The type of the frame adopts a private definition, the source MAC address of the frame is the MAC address of the sending interface of the first encryption bridge, and the destination address of the frame is a multicast MAC address adopting a private definition.

[0098] It should be understood that when sending a policy negotiation frame, it is also determined whether the length of the policy negotiation frame exceeds the MTU of the sending interface, and if so, the frame is fragmented.

[0099] In one embodiment, the step S101 of sending the encrypted policy negotiation frame to the second encryption bridge includes the following steps:

[0100] The time interval for sending the encrypted policy negotiation frame is less than or equal to half of the session key usage time threshold, and the same encrypted policy negotiation frame is sent continuously m times each time.

[0101] It should be noted that the time interval for sending policy negotiation frames is no greater than half of the session key usage time threshold, and the same policy negotiation frame is sent three times consecutively each time to ensure immediate key update and reliable transmission.

[0102] In one embodiment, the policy count byte of the policy negotiation frame supports a maximum of 127 policy counts, and the highest bit of this byte is added with a flag indicating whether confirmation is required. If this flag is 1, the recipient is required to send a confirmation frame, and the sending encryption bridge starts a timer queue and queues the policy negotiation frame for periodic retransmission until the policy negotiation frame expires (the session key expires) or all receiving bridges in the security domain have responded with confirmation frames. If this flag is 0, no confirmation frame response is required.

[0103] In one embodiment, before the step S101: sending the policy negotiation frame to the second encryption bridge, the method further includes the following steps:

[0104] Send a key injection request to the quantum key distribution network;

[0105] The master key returned by the quantum key distribution network is obtained through the first secure storage medium integrated in the sending-end encryption bridge, and a master key pool is established based on the master key. A key bitmap is used to identify whether each master key has been used, where each encryption bridge in the same security domain shares a master key with the same master key ID.

[0106] It should be noted that the first secure storage medium in this embodiment is a large-capacity secure storage medium such as a secure TF card or a secure U shield. After receiving the key injection request sent by the encryption bridge, the quantum key distribution network QKD uses the secure storage medium to pre-inject a large number of master keys offline to each encryption bridge device node in the domain. The key format is a 4-byte key ID + n-byte key and an n-byte initialization vector (n is related to the encryption algorithm). Each device in the same security domain shares the same master key identified by the same key ID, establishes a master key pool, and uses a key bitmap to indicate whether the key has been used.

[0107] In one embodiment, before sending the policy negotiation frame to the second encryption bridge, the method further includes the following steps:

[0108] Defining the Ethernet interface type of the sending end encryption bridge, wherein the interface not connected to other encryption bridges of the same type is defined as a dense port, and the interface connected to other encryption bridges of the same type is defined as an open port;

[0109] The encrypted port is used to add the source MAC address learned by the port to the local encryption policy sub-table, and to periodically clear the encryption policy sub-table corresponding to the source MAC address not received from the encrypted port within a set time.

[0110] It should be noted that the processing of data frames sent and received by the open port is no different from that of general bridge devices. In addition to performing the functions of an ordinary bridge interface, the secret port establishes an encryption policy sub-table for the newly learned source MAC address and starts a timer to regularly clear the encryption policy sub-table corresponding to the source MAC that has not been received from the secret port within a period of time.

[0111] In one embodiment, the step S104 of encrypting and encapsulating the Ethernet data frame according to the corresponding encryption policy item to obtain an encrypted Ethernet frame and sending it to the second encryption bridge includes the following steps:

[0112] After encrypting and encapsulating the Ethernet data frame according to the corresponding encryption policy item, the frame format is: a new Ethernet frame header + a decryption index + a framing ID + an original Ethernet frame + a second integrity check value, wherein the information of the new Ethernet frame header includes an encapsulation source MAC, an encapsulation destination MAC, and an encapsulation frame protocol type, wherein the second integrity check value is calculated using a keyed hash algorithm HMAC on the entire Ethernet frame using a currently used numbered session key;

[0113] The unregistered bit in the new Ethernet frame header is used to mark the serial number of the adopted session key, and the usage count of the currently used serial numbered session key is increased by 1.

[0114] It should be noted that the sending end encryption bridge device node receives the outbound Ethernet data frame from the encrypted port and forwards it from the open port. It first searches the local corresponding encryption policy subtable based on the source MAC of the outbound Ethernet data frame (that is, the source MAC of the Ethernet data frame is the same as the source MAC of the encryption policy subtable), and then searches the corresponding encryption policy item from the corresponding encryption policy subtable based on the destination MAC of the Ethernet data frame. If the corresponding encryption policy item is not hit, it is discarded or forwarded in plain text according to the default setting. If the corresponding encryption policy item is found, the Ethernet data frame is encrypted and encapsulated according to the encryption policy item.

[0115] Specifically, the process of encrypting and encapsulating outbound Ethernet data frames is as follows:

[0116] The session key currently used in the encryption policy item is used to calculate the ICV integrity check value (including the new Ethernet frame header) using the keyed hash algorithm HMAC for the entire Ethernet data frame to obtain the second integrity check value. The original Ethernet data frame is then symmetric encrypted (the encryption mode is CBC (integer multiples of the algorithm block) + CFB (the remainder beyond the integer multiples of the algorithm block), without adding additional data). The specific frame format of the encrypted Ethernet frame after encryption and encapsulation is as follows:

[0117] 14-byte new Ethernet frame header (encapsulated source MAC + encapsulated destination MAC + encapsulated frame protocol type) + 4-byte decryption index + 2-byte framing ID + original Ethernet frame + ICV (second integrity check value).

[0118] Among them, the 2-byte protocol type field of the new Ethernet frame header adopts a private definition and still does not occupy the 13th bit of the protocol type field (that is, the Ethernet frame protocol type field has a total of 16 bits from low to high, and the 13th bit is not registered). This bit is used to mark whether session key No. 0 or No. 1 is used. The two session keys with different numbers serve as primary and backup for each other. By adding 1 to the usage count of the currently used session key, when the usage count of the current session key exceeds the threshold, the number of the currently used key of all encryption policy items in the encryption policy subtable is switched, and the key component corresponding to the switched key number is updated by collecting random numbers in real time.

[0119] The 4-byte decryption index value is the 16 bits before and after the decryption index value in the encryption policy item swapped, that is, the destination MAC number | | subtable number.

[0120] It should be noted that by adopting the encrypted tunnel encapsulation method of the inner and outer layers of MAC addresses in the Layer 2 Ethernet link, combined with a simple and efficient index generation method, a highly secure and reliable IP-free Layer 2 security channel is achieved.

[0121] In one embodiment, before sending the encrypted Ethernet frame to the second encryption bridge, the method further includes the following steps:

[0122] Before actual framing, the total length of the encapsulated Ethernet frame is calculated. If the length of the new frame after encapsulation exceeds the MTU of the sending interface, the framing counter of the sending interface is incremented by 1 and assigned to the framing ID field. The highest bit of the framing ID field is set to 1, and the original Ethernet frame is divided into two new Ethernet frame data segments for encapsulation and encryption. The two new Ethernet frames have the same encapsulation source MAC, encapsulation destination MAC, decryption index, and framing ID.

[0123] If the length of the new frame after encapsulation does not exceed the MTU of the sending interface, the highest bit of the Frame ID field is set to 0.

[0124] In this embodiment, the encryption bridge maintains a 2-byte frame counter for each visible port (actually using 15 bits, reset to 0 if the 15-bit limit is exceeded). Before actual framing, the total length of the encapsulated Ethernet frame is calculated. If the length of the new frame after encapsulation exceeds the MTU of the sending interface, the frame counter of the sending visible port is incremented by 1 and assigned to the Frame ID field. The highest bit of the Frame ID field is set to 1, and the original Ethernet frame is then divided into two data segments for encapsulation and encryption. The two new Ethernet frames have the same encapsulation source MAC, encapsulation destination MAC, decryption index, and frame ID. If the length does not exceed the MTU, the highest bit of the Frame ID field is set to 0.

[0125] It should be noted that this embodiment achieves zero-frame-loss reliable transmission of the encrypted tunnel through a simple and efficient frame segmentation and merging processing method, as well as switching between primary and backup session keys, without affecting Layer 2 network services.

[0126] This embodiment proposes a method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution. This method primarily targets application scenarios where Layer 2 Ethernet frame security encapsulation and encryption cannot be achieved through conventional methods, as there are no IP addresses and, therefore, keys cannot be distributed or secure tunnels cannot be established through conventional methods. By leveraging the bridge-based MAC automatic learning capability and multicast point-to-multipoint information distribution, this method enables automatic learning of encryption and decryption policy-related parameters, automatic synthesis of encryption and decryption policies, and peer-to-peer negotiation of session keys. Combined with a relatively reasonable and efficient Ethernet tunnel encapsulation format design and processing flow, this method implements a lightweight, highly secure, and reliable IP-free Layer 2 Ethernet security channel.

[0127] Example 2

[0128] like Figure 2 As shown, the second embodiment of the present invention proposes a method for implementing a self-organized decryption tunnel of an Ethernet link using quantum key distribution, which is applied to a receiving-end encryption bridge. The method includes the following steps:

[0129] S201, receiving a policy negotiation frame sent by a first encryption bridge, where the first encryption bridge and the receiving end encryption bridge are in the same security domain;

[0130] It should be noted that the first encryption bridge, as the sender, belongs to the same security domain as the receiving encryption bridge. The encryption bridges all send registration requests and identity binding service requests to the management and control platform in advance. After all encryption bridges complete the registration and identity binding services, the security domain is defined by the management and control platform.

[0131] It should be noted that the policy negotiation frame consists of multiple negotiation policies, each of which corresponds to an encryption policy subtable and its source MAC address of the encryption bridge, and its content is the source MAC address and session key component of the subtable.

[0132] S202: Based on each negotiation policy in the policy negotiation frame, each encryption policy sub-table in the local encryption policy table and each decryption policy sub-table in the decryption policy table are refreshed;

[0133] It should be noted that members within the security domain manage the local encryption policy table based on the received negotiation policy frame, and manage the locally stored decryption policy table based on the negotiation policy frame and the encryption policy table, thereby realizing the automatic exchange of network parameters and security parameters between members within the security domain.

[0134] S203: Receive an encrypted Ethernet frame sent by the first encryption bridge, where the encrypted Ethernet frame is obtained by the sending-end encryption bridge encrypting and encapsulating an outbound Ethernet data frame based on its local corresponding encryption policy item;

[0135] S204. According to the source MAC address of the encrypted Ethernet frame, the corresponding decryption policy subtable is searched from its local decryption policy table, the corresponding decryption policy item is searched based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and the encrypted Ethernet frame is decrypted and decapsulated according to the corresponding decryption policy item to obtain the Ethernet data frame.

[0136] It should be noted that, in this embodiment, the receiving encryption bridge first searches the local decryption policy table for the corresponding decryption policy subtable based on the source MAC address of the encrypted Ethernet frame, and then searches the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and uses the decryption policy item to decrypt and decapsulate the encrypted Ethernet frame. By utilizing the MAC automatic learning of the encryption bridge port and combining the point-to-multipoint policy distribution method of multicast, the automatic exchange of network parameters and security parameters between members in the security domain is realized, and on this basis, the automatic generation of security policies and session keys is realized, which safely and efficiently solves the security policy distribution and management problems of Layer 2 Ethernet devices without IP addresses; and by adopting the decryption tunnel decapsulation method of internal and external MAC addresses in the Layer 2 Ethernet link, a highly secure and reliable Layer 2 security channel without IP is realized.

[0137] In one embodiment, before the step S201: receiving the policy negotiation frame sent by the first encryption bridge, the method further includes the following steps:

[0138] When the sending end encryption bridge is started, a local encryption policy table is established, wherein the encryption policy table includes a plurality of encryption policy sub-tables, the MAC address of each encryption policy sub-table corresponds to a source MAC address of an Ethernet data frame received by the encryption port of the sending end encryption bridge, and each encryption policy sub-table in the initially established encryption policy table includes the MAC address of each encryption policy sub-table and a session key component;

[0139] Based on the local encryption policy table, a corresponding decryption policy table is established, and the decryption policy table includes multiple decryption policy sub-tables. The MAC address of each decryption policy sub-table corresponds to a source MAC address of the Ethernet data frame received by the open port of this encryption bridge. Each decryption policy sub-table in the initially established decryption policy table includes the MAC address of each decryption policy sub-table.

[0140] It should be noted that this encryption bridge uses the corresponding encryption policy items in the encryption policy table to encrypt and encapsulate outgoing Ethernet data frames, and uses the corresponding decryption policy items in the decryption policy table to decrypt and decapsulate received encrypted Ethernet data frames.

[0141] It should be noted that the encryption policy table and decryption policy table initially established by the encryption bridge are managed through policy negotiation frames sent by other members in the same security domain, realizing the automatic exchange of network parameters and security parameters between members in the security domain, and on this basis realizing the automatic generation of security policies and session keys.

[0142] In one embodiment, when the encryption policy table is established, each encryption policy sub-table therein only contains the sub-table source MAC address and the session key component, and the addition or update of its table entries comes from the key negotiation frame; when the decryption policy table is established, each decryption policy sub-table only contains the sub-table source MAC address, and the addition or update of its table entries comes from the key negotiation frame and the table entries of the encryption policy sub-table.

[0143] Specifically, each encryption policy entry in the encryption policy subtable includes the destination MAC address, the destination MAC number (2 bytes), the encapsulated source MAC address, the encapsulated destination MAC address, the number of the currently used session key, different numbered session keys, and the initialization vector and key usage count corresponding to the session key;

[0144] Each decryption policy item in the decryption policy subtable includes a decryption index, a destination MAC address, an original source MAC address, an original destination MAC address, session keys of different numbers, an initialization vector corresponding to the session key, and a key usage count.

[0145] Among them, the session keys are numbered 0 and 1 respectively, and the relevant data of each numbered session key includes the initialization vector and the key usage count; the destination MAC number in the encryption policy item comes from the source MAC number of the key negotiation frame sent by other encryption network bridges in the same security domain, and is not uniformly numbered in the local encryption policy subtable of this encryption bridge; and the source MAC address in the key negotiation frame comes from the encryption policy subtable number of the encryption bridge that sends the key negotiation frame, that is, it is the same source MAC address as the encryption policy subtable.

[0146] Among them, a decryption policy table is established based on the encryption policy table. The table consists of multiple decryption policy sub-tables. Each decryption policy sub-table is represented by a unique MAC address. The MAC address corresponds to a source MAC address of the Ethernet frame received by the bright port of this bridge (corresponding to the encapsulation destination MAC in the encryption policy item), which is called the sub-table source MAC. Different decryption policy sub-tables have different sub-table source MACs.

[0147] The decryption policy subtable consists of multiple decryption policy items. Each decryption policy item includes a 4-byte decryption index, destination MAC address, original (before encapsulation) source MAC address, original (before encapsulation) destination MAC address, two session keys numbered 0 and 1, the initialization vector of the session key, and the key usage count.

[0148] In one embodiment, the source MAC address of each decryption policy sub-table in the decryption policy table is the encapsulated destination MAC address of each encryption policy sub-table in the corresponding encryption policy table; the destination MAC address, original source MAC address, original destination MAC address, session keys with different numbers and initialization vectors corresponding to the session keys and key usage counts in the decryption policy items in the decryption policy sub-table are from all the encapsulated source MAC addresses, destination MAC addresses, source MAC addresses corresponding to the encryption policy sub-tables, session keys with different numbers and initialization vectors corresponding to the session keys and key usage counts in the encryption policy items of each encryption policy sub-table whose source MAC addresses are the corresponding source MAC addresses of this decryption policy sub-table; the 4-byte decryption index value in the decryption policy item is composed of the 2-byte encryption policy sub-table number and the 2-byte destination MAC number of the corresponding encryption policy item.

[0149] In one embodiment, before receiving the policy negotiation frame sent by the first encryption bridge, the method further includes:

[0150] Send a key injection request to the quantum key distribution network;

[0151] The master key returned by the quantum key distribution network is obtained through the second secure storage medium integrated in the receiving-end encryption bridge, and a master key pool is established based on the master key. A key bitmap is used to identify whether each master key has been used, where each encryption bridge in the same security domain shares a master key with the same master key ID.

[0152] In one embodiment, when the first encryption bridge sends a negotiation policy frame encrypted using a master key, the receiving encryption bridge first selects a master key corresponding to the master key ID from its own integrated second secure storage medium, performs an integrity check on the encrypted negotiation policy frame, and decrypts it to obtain a negotiation policy frame.

[0153] It should be noted that if the integrity check fails, the data transmission process will be terminated directly.

[0154] In this embodiment, the second secure storage medium stores a large number of master keys pre-filled by the quantum key distribution network. The second secure storage medium can use a large-capacity secure storage medium such as a secure TF card or a secure U shield. The quantum key distribution network uses the secure storage medium to pre-fill a large number of master keys offline to each encryption bridge device node in the domain. The key format is a 4-byte key ID + n-byte key and an n-byte initialization vector (n is related to the encryption algorithm). Each encryption bridge device in the same security domain shares the same master key identified by the same key ID.

[0155] This embodiment divides the security domain and pre-fills a large number of identical master keys for each device node in the security domain and uses them randomly, thereby safely and efficiently solving the problem of identity authentication and distribution of session keys between bridge device nodes with encryption intercommunication requirements.

[0156] In one embodiment, step S202 of refreshing each encryption policy sub-table in the local encryption policy table and each decryption policy sub-table in the decryption policy table based on each negotiation policy in the policy negotiation frame specifically includes the following steps:

[0157] S221. Based on each negotiation policy in the policy negotiation frame, add or update an encryption policy item in all local encryption policy subtables of the second encryption bridge, and the encryption policy items are numbered incrementally starting from 1, wherein the destination MAC address of the encryption policy item is set to the source MAC of the encryption policy subtable in the negotiation policy, the destination MAC number of the encryption policy item is set to the number of the encryption policy subtable in the negotiation policy, the encapsulation source MAC address and the encapsulation destination MAC address of the encryption policy item are respectively set to the MAC address of the interface on which the second encryption bridge receives the policy negotiation frame and the source MAC address of the policy negotiation frame, and the session key of the encryption policy item is respectively formed by the exclusive OR value of the session key component of the encryption policy subtable with the same number and the session key component of the negotiation policy;

[0158] S222: For each encryption policy item generated by the negotiation policy, add or update a decryption policy item in all local decryption policy sub-tables of the second encryption bridge.

[0159] It should be noted that for each negotiation policy in the policy negotiation frame, an encryption policy item is added to all encryption policy subtables of the encryption bridge that receives the policy negotiation frame. The encryption policy number increases from 1, and the destination MAC address of the encryption policy is set to the subtable source MAC in the negotiation policy. If there is a policy item with the same destination MAC in the encryption policy subtable, the policy item will be updated. The destination MAC is the primary key of the encryption policy subtable and is unique.

[0160] Furthermore, in step S221, the session key includes a session key numbered 0 and a session key numbered 1, and the two numbered session keys serve as primary and backup for each other. The session keys 0 and 1 in the updated or added encryption policy item are respectively the exclusive OR values ​​of the session key component of the encryption policy subtable with the same number and the session key component of the negotiation policy. The initialization vectors 0 to 1 generated by the session key 0 or 1 are generated by the following formula:

[0161] Initialization vector = E(session key, (source MAC of encryption policy subtable | source MAC of negotiation policy subtable) || (encapsulation source MAC of encryption policy | encapsulation destination MAC of encryption policy) || padding)

[0162] In the above formula, E(K, D) represents the symmetric encryption operation on the data D using the key K, and padding is the padding data (the encrypted data length is padded to the encryption algorithm block length, and the padding method is to repeatedly fill in the 10 numbers from 0 to 9 until the length requirement is met).

[0163] Initially, session key 0 and initialization vector 0 are used, and a timer and usage count are enabled for the currently used key. When the timer or usage count for an encryption policy in the encryption policy subtable exceeds a threshold, the key numbers currently used by all encryption policies in the subtable are switched, and the key components corresponding to the switched key numbers are updated using random numbers collected in real time. Because key numbers are switched uniformly within the subtable, all encryption policies in the subtable use the same key number at the same time.

[0164] In one embodiment, in step S222, a decryption policy is added or updated corresponding to each encryption policy generated by the negotiation policy of the policy negotiation frame.

[0165] If the encapsulation destination MAC in the encryption policy entry does not have a corresponding subtable source MAC in the decryption policy subtable, a new decryption policy subtable is created with the encapsulation destination MAC in the encryption policy as the source MAC. Encryption policies with the same encapsulation destination MAC (which can be in different encryption policy subtables, or the same encryption policy subtable can have multiple encryption policies with the same encapsulation destination MAC) have corresponding decryption policies in the same decryption policy subtable (the subtable source MAC is the encapsulation destination MAC).

[0166] In one embodiment, this embodiment defines the type of each Ethernet interface of the encryption bridge: the interface not connected to other encryption bridges of the same type is defined as a encrypted port, and the interface connected to other encryption bridges of the same type is defined as an open port.

[0167] Among them, the processing of data frames sent and received by the open port is no different from that of general bridge devices; in addition to performing the functions of an ordinary bridge interface, the secret port establishes an encryption policy sub-table for the newly learned source MAC address, and starts a timer to regularly clear the encryption policy sub-table corresponding to the source MAC that has not been received from the secret port within a period of time.

[0168] In one embodiment, step S204: searching a corresponding decryption policy sub-table in a local decryption policy table according to the source MAC address of the encrypted Ethernet frame, searching a corresponding decryption policy item based on a decryption index of each decryption policy item in the corresponding decryption policy sub-table, and decrypting and decapsulating the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame, includes the following steps:

[0169] S241. Search the corresponding decryption policy sub-table from the local decryption policy table according to the source MAC address of the encrypted Ethernet frame;

[0170] It should be noted that the receiving end encryption bridge device node decrypts and decapsulates the inbound Ethernet data frame received from the open port, whose destination MAC is the MAC address of this interface and conforms to the private protocol type definition. First, it searches the local decryption policy table for the corresponding decryption policy subtable based on the source MAC address of the encrypted Ethernet frame.

[0171] S242. When the encrypted Ethernet frame is not framed, search for the corresponding decryption policy item according to the decryption index of each decryption policy item in the corresponding decryption policy subtable, perform an ICV integrity check on the entire encrypted Ethernet frame using a keyed cryptographic hash algorithm HMAC based on the session key in the corresponding decryption policy item, and perform a symmetric decryption operation on the original Ethernet frame after the integrity check passes to obtain the original Ethernet frame and forward it;

[0172] If the frame is not fragmented, the corresponding decryption policy item is searched based on the decryption index. If no corresponding decryption policy item is found, the encrypted Ethernet frame is discarded or forwarded according to the default settings. If a corresponding decryption policy item is found, the decryption policy's session key 0 or 1 is selected based on bit 13 of the Ethernet frame protocol field. The entire Ethernet frame is first subjected to an ICV integrity check using the keyed cryptographic hash algorithm HMAC. If the integrity check passes, the original Ethernet frame is symmetric decrypted. If the integrity check fails, the frame is discarded. The decrypted original Ethernet frame is then forwarded according to the normal bridge device processing flow.

[0173] S243. When the encrypted Ethernet frame is a frame, search the frame table of the corresponding decryption strategy subtable for an Ethernet frame with the same frame ID, decrypt and decapsulate the two frames respectively, obtain two original frames, splice them into a complete original Ethernet frame, and then forward them.

[0174] It should be noted that if the received encrypted Ethernet frame is a fragmented frame, the decryption policy subtable's fragmented frame table is searched for an Ethernet frame with the same fragmented frame ID based on the lower 15 bits of the fragmented frame ID. If no fragmented frame with the same ID exists, the frame is added to the fragmented frame table. If a fragmented frame with the same ID is found, the two fragmented frames are subjected to a decryption policy search, integrity check, and decryption respectively. The two original fragmented frames are then directly concatenated into a complete original Ethernet frame and forwarded according to the processing flow of a standard network bridge device.

[0175] It should be noted that, in order to achieve fast frame search, the frame table is a 15 An array of elements, each element consists of a frame ID and the corresponding Ethernet frame, and can be directly retrieved based on the frame ID.

[0176] It should be noted that through a simple and efficient frame segmentation and merging processing method, as well as the switching use of the primary and backup keys, zero-frame loss and reliable transmission of the encrypted tunnel is achieved without affecting the Layer 2 network services.

[0177] This embodiment is mainly aimed at application scenarios where Layer 2 Ethernet frame security encapsulation and encryption are required in cases where IP addresses are not available and therefore keys cannot be distributed and secure tunnels cannot be established through conventional means. Based on the automatic MAC learning capability of the bridge and the point-to-multipoint information distribution method of multicast, automatic learning of decryption policy-related parameters and automatic synthesis of decryption policies are performed, as well as peer-to-peer negotiation of session keys. Combined with a relatively reasonable and efficient Ethernet tunnel decapsulation format design and processing flow, a lightweight, highly secure, and highly reliable IP-free Layer 2 Ethernet security channel is implemented.

[0178] Example 3

[0179] like Figure 3 As shown, the third embodiment of the present invention proposes a method for implementing a self-organized encryption and decryption tunnel of an Ethernet link using quantum key distribution, wherein the second encryption bridge is a member of the security domain of the first encryption bridge, and the method includes the following steps:

[0180] S301: The first encryption bridge sends a policy negotiation frame to the second encryption bridge, where the policy negotiation frame includes multiple negotiation policies, each of which contains a source MAC address and a session key component of a corresponding encryption policy subtable.

[0181] It should be noted that each encryption bridge establishes an encryption policy table when it is started, and establishes a decryption policy table based on the encryption policy table. The encryption policy table and the decryption policy table can be refreshed and managed according to the policy negotiation frame.

[0182] S302: The second encryption bridge receives the policy negotiation frame and, based on each negotiation policy in the policy negotiation frame, refreshes each encryption policy sub-table in the encryption policy table and each decryption policy sub-table in the decryption policy table of the second encryption bridge.

[0183] S303: The first encryption bridge searches a local encryption policy table for a corresponding encryption policy subtable based on the source MAC address of the outbound Ethernet data frame, searches the corresponding encryption policy subtable for a corresponding encryption policy item based on the destination MAC address of the outbound Ethernet data frame, encrypts and encapsulates the Ethernet data frame according to the corresponding encryption policy item, obtains an encrypted Ethernet frame, and sends the encrypted Ethernet frame to the second encryption bridge.

[0184] S304. The second encryption bridge receives the encrypted Ethernet frame, searches for the corresponding decryption policy subtable from the local decryption policy table according to the source MAC address of the encrypted Ethernet frame, searches for the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypts and decapsulates the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame.

[0185] This embodiment utilizes the automatic MAC learning of the bridge port, combined with the point-to-multipoint policy distribution method of multicast, to realize the automatic exchange of network parameters and security parameters between members in the security domain. On this basis, it realizes the automatic generation of security policies and session keys, and safely and efficiently solves the security policy distribution and management problems of Layer 2 Ethernet devices without IP addresses. By adopting the encrypted tunnel encapsulation method of internal and external MAC addresses in the Layer 2 Ethernet link, a highly secure and reliable IP-free Layer 2 security channel is realized.

[0186] In one embodiment, before the first encryption bridge sends the policy negotiation frame to the second encryption bridge, the method further includes the following steps:

[0187] When the first encryption bridge and the second encryption bridge are started, they respectively establish a local encryption policy table, wherein the encryption policy table includes a plurality of encryption policy sub-tables, and the MAC address of each encryption policy sub-table corresponds to a source MAC address of an Ethernet data frame received by a cryptographic port of the encryption bridge. Each encryption policy sub-table in the initially established encryption policy table includes the MAC address of each encryption policy sub-table and a session key component, wherein the two session key components are numbered 0 and 1, and are random numbers regularly collected and updated by the random number generator of the encryption bridge.

[0188] The first encryption bridge and the second encryption bridge respectively establish corresponding decryption policy tables based on the local encryption policy table. The decryption policy table includes multiple decryption policy sub-tables. The MAC address of each decryption policy sub-table corresponds to a source MAC address of the Ethernet data frame received by the open port of this encryption bridge. Each decryption policy sub-table in the initially established decryption policy table includes the MAC address of each decryption policy sub-table.

[0189] In one embodiment, if Figure 4 As shown, each encryption policy item in the encryption policy subtable includes the destination MAC address, destination MAC number, encapsulation source MAC address, encapsulation destination MAC address, the number of the currently used session key, different numbered session keys, and the initialization vector and key usage count corresponding to the session key;

[0190] Each decryption policy entry in the decryption policy subtable includes a 4-byte decryption index, a destination MAC address, an original (before encapsulation) source MAC address, an original (before encapsulation) destination MAC address, two session keys numbered 0 and 1, an initialization vector for the session key, and a key usage count;

[0191] Among them, the source MAC address of each decryption policy sub-table in the decryption policy table is the encapsulated destination MAC address of each encryption policy sub-table in the corresponding encryption policy table; the destination MAC address, original source MAC address, original destination MAC address, session keys with different numbers and initialization vectors corresponding to session keys and key usage counts in the decryption policy items in the decryption policy sub-table are from all the encapsulated source MAC addresses, destination MAC addresses, source MAC addresses corresponding to the encryption policy sub-table, session keys with different numbers and initialization vectors corresponding to session keys and key usage counts in the encryption policy items of each encryption policy sub-table whose source MAC address is the corresponding source MAC address of this decryption policy sub-table; the decryption index in the decryption policy item includes the encryption policy sub-table number and destination MAC number of the corresponding encryption policy item.

[0192] In one embodiment, the step S301 of the first encryption bridge sending a policy negotiation frame to the second encryption bridge includes the following steps:

[0193] The first encryption bridge generates the policy negotiation frame according to each encryption policy sub-table in the local encryption policy table and its source MAC address;

[0194] A master key is randomly selected from the first secure storage medium, the policy negotiation frame is encrypted using the master key, a check value of the policy negotiation frame is calculated using a keyed hash algorithm, and then sent to the second encryption bridge, wherein the format of the encrypted policy negotiation frame is:

[0195] 14-byte Ethernet frame header (source MAC + destination MAC + frame type) + 1-byte frame policy count / confirmation tag + 4-byte master key ID + k*(subtable number + subtable source MAC + n-byte subtable session key component 0 + n-byte subtable session key component 1) + ICV (integrity check value), where k represents the number of policies contained in this frame.

[0196] It should be noted that the master key stored in the first secure storage medium is pre-filled with the quantum key distribution system, and each encryption bridge device node in the security domain is pre-filled with a large number of identical master keys and used randomly, which can safely and efficiently solve the problem of identity authentication and distribution of session keys between bridge device nodes with encryption intercommunication requirements.

[0197] In one embodiment, the first encryption bridge sending the encrypted policy negotiation frame to the second encryption bridge includes:

[0198] When it is determined that the length of the encrypted policy negotiation frame exceeds the interface MTU, the encrypted policy negotiation frame is divided into multiple frames and then sent to the second encryption bridge;

[0199] The type of the frame adopts a private definition, the source MAC address of the frame is the MAC address of the sending interface of the first encryption bridge, and the destination address of the frame is a multicast MAC address adopting a private definition.

[0200] In one embodiment, the first encryption bridge sends the policy negotiation frame at an interval that is less than or equal to half of a session key usage time threshold, and sends the same policy negotiation frame m times in succession each time.

[0201] In one embodiment, the highest bit of the byte of the current frame policy count is a flag indicating whether confirmation is required. When the flag is 1, the method further includes:

[0202] The first encryption network bridge starts a timer queue and adds the encryption policy negotiation frame to the timer queue and retransmits it periodically until the encryption policy negotiation frame becomes invalid or the second encryption network bridge replies with a confirmation frame.

[0203] It should be noted that the policy count byte in this frame supports a maximum of 127 policy counts. The highest bit of this byte indicates whether an acknowledgment is required. If this flag is 1, the receiver must send an acknowledgment frame. The sending bridge starts a timer queue and queues the frame for periodic retransmission until the frame expires (due to session key expiration) or all bridges in the security domain reply with acknowledgment frames.

[0204] In one embodiment, when the second encryption bridge receives the encrypted policy negotiation frame sent by the first encryption bridge, the second encryption bridge first selects a master key corresponding to the master key ID from the second secure storage medium integrated in itself, and uses the master key to perform integrity verification and decryption on the encrypted policy negotiation frame to obtain the policy negotiation frame.

[0205] It should be noted that the first secure storage medium and the second secure storage medium can both be large-capacity secure storage media such as a secure TF card or a secure U shield. The first encryption bridge and the second encryption bridge first send key injection to the quantum key distribution network. The quantum key distribution network pre-injects a large number of master keys offline to each encryption bridge device node in the domain through the corresponding secure storage medium. The key format is a 4-byte key ID + n-byte key and n-byte initialization vector (n is related to the encryption algorithm). Each device in the same security domain shares the same master key identified by the same key ID.

[0206] Inject the pre-filled master key into the encryption bridge device node in the domain, establish a master key pool, and use the key bitmap to indicate whether the key has been used.

[0207] In one embodiment, step S302, in which the second encryption bridge receives the policy negotiation frame and, based on each negotiation policy in the policy negotiation frame, refreshes each encryption policy sub-table in the encryption policy table and each decryption policy sub-table in the decryption policy table of the second encryption bridge, includes the following steps:

[0208] The second encryption bridge receives the policy negotiation frame, and based on each negotiation policy in the policy negotiation frame, adds or updates an encryption policy item in all local encryption policy subtables of the second encryption bridge, and the numbering of the encryption policy items increases from 1, wherein the destination MAC address of the encryption policy item is set to the source MAC of the encryption policy subtable in the negotiation policy, the destination MAC number of the encryption policy item is set to the number of the encryption policy subtable in the negotiation policy, the encapsulation source MAC address and the encapsulation destination MAC address of the encryption policy item are respectively set to the MAC address of the interface on which the second encryption bridge receives the policy negotiation frame and the source MAC address of the policy negotiation frame, the session keys No. 0 and No. 1 of the encryption policy are respectively the exclusive OR values ​​of the session key component of the encryption policy subtable with the same number and the session key component of the negotiation policy, and the initialization vector is generated by the following formula:

[0209] Initialization vector = E(session key, (source MAC of encryption policy subtable | source MAC of negotiation policy subtable) || (encapsulation source MAC of encryption policy | encapsulation destination MAC of encryption policy) || padding)

[0210] In the above formula, E(K, D) represents the symmetric encryption operation on the data D using the key K, and padding is the padding data (the encrypted data length is padded to the encryption algorithm block length, and the padding method is to repeatedly fill in the 10 numbers from 0 to 9 until the length requirement is met).

[0211] The second encryption bridge adds or updates a decryption policy item in all local decryption policy sub-tables of the second encryption bridge corresponding to each encryption policy item generated by the negotiation policy.

[0212] In one embodiment, session key 0 and initialization vector 0 are initially used, and a timer and usage count are enabled for the currently used key. When the timer or usage count for an encryption policy entry in the encryption policy subtable exceeds a threshold, the current key numbers for all encryption policies in the subtable are switched, and the key components corresponding to the switched key numbers are updated by collecting random numbers in real time.

[0213] Because the key number in the sub-table is switched uniformly, all encryption policies in the sub-table use the same key number at the same time.

[0214] In one embodiment, when adding or updating a decryption policy for each encryption policy generated by the negotiation policy of the policy negotiation frame, if the encapsulation destination MAC in the encryption policy does not have a corresponding decryption policy subtable (subtable source MAC), a new decryption policy subtable is created with the source MAC being the encapsulation destination MAC in the encryption policy. The decryption policies corresponding to encryption policies with the same encapsulation destination MAC (which can be located in different encryption policy subtables, or the same encryption policy subtable can have multiple encryption policies with the same encapsulation destination MAC) are located in the same decryption policy subtable (the subtable source MAC being the encapsulation destination MAC).

[0215] In one embodiment, before step S301, the method further includes:

[0216] Define the type of each Ethernet interface of the encryption bridge: the interface not connected to other encryption bridges of the same type is defined as a encrypted port, and the interface connected to other encryption bridges of the same type is defined as an open port.

[0217] Among them, the processing of data frames sent and received by the open port is no different from that of general bridge devices; in addition to performing the functions of an ordinary bridge interface, the secret port establishes an encryption policy sub-table for the newly learned source MAC address, and starts a timer to regularly clear the encryption policy sub-table corresponding to the source MAC that has not been received from the secret port within a period of time.

[0218] In one embodiment, step S303, in which the first encryption bridge searches a local encryption policy table for a corresponding encryption policy subtable based on the source MAC address of the outbound Ethernet data frame, searches the corresponding encryption policy item in the corresponding encryption policy subtable based on the destination MAC address of the outbound Ethernet data frame, and encrypts and encapsulates the Ethernet data frame based on the corresponding encryption policy item to obtain an encrypted Ethernet frame and sends it to the second encryption bridge, includes the following steps:

[0219] The first encryption bridge searches the local encryption policy table for a corresponding encryption policy sub-table according to the source MAC address of the outbound Ethernet data frame;

[0220] Determine whether there is a corresponding encryption policy item in the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame;

[0221] If yes, encrypt and encapsulate the Ethernet data frame according to the corresponding encryption policy item to obtain an encrypted Ethernet frame and send it to the second encryption bridge;

[0222] If not, the Ethernet data frame is discarded or forwarded according to the default setting.

[0223] In one embodiment, the encrypting and encapsulating the Ethernet data frame according to the corresponding encryption policy item to obtain an encrypted Ethernet frame and sending it to the second encryption bridge includes:

[0224] After encrypting and encapsulating the Ethernet data frame according to the corresponding encryption policy item, the frame format is: a new Ethernet frame header + a decryption index + a framing ID + an original Ethernet frame + an integrity check value, wherein the information of the new Ethernet frame header includes an encapsulation source MAC, an encapsulation destination MAC, and an encapsulation frame protocol type, wherein the integrity check value is calculated using a keyed hash algorithm HMAC on the entire Ethernet frame using a currently used numbered session key;

[0225] Using the unregistered bits in the new Ethernet frame header to mark the number of the used session key, and adding 1 to the usage count of the currently used session key;

[0226] Before actual framing, the total length of the encapsulated Ethernet frame is calculated. If the length of the new frame after encapsulation exceeds the MTU of the sending interface, the framing counter of the sending interface is incremented by 1 and assigned to the framing ID field. The highest bit of the framing ID field is set to 1, and the original Ethernet frame is divided into two new Ethernet frame data segments for encapsulation and encryption. The two new Ethernet frames have the same encapsulation source MAC, encapsulation destination MAC, decryption index, and framing ID.

[0227] If the length of the new frame after encapsulation does not exceed the MTU of the sending interface, the highest bit of the Frame ID field is set to 0.

[0228] It should be noted that the first encryption bridge device node encrypts and encapsulates outbound Ethernet data frames received from the encrypted port and forwarded from the open port. First, it searches the encryption policy subtable based on the source MAC (the source MAC is the same as the source MAC in the encryption policy subtable). Then, it searches the encryption policy based on the destination MAC. If no match is found, the frame is discarded or forwarded in plain text according to the default settings. The Ethernet frame is encrypted and encapsulated according to the encryption policy. The specific frame format is as follows:

[0229] 14-byte new Ethernet frame header (encapsulated source MAC + encapsulated destination MAC + encapsulated frame protocol type) + 4-byte decryption index + 2-byte framing ID + original Ethernet frame + ICV (second integrity check value).

[0230] The currently used session key is used to calculate the ICV integrity check value of the entire Ethernet frame (including the new Ethernet frame header) using the keyed hash algorithm HMAC. The original Ethernet frame is symmetric encrypted (the encryption mode is CBC (integer multiple of the algorithm block) + CFB (the remainder beyond the integer multiple of the algorithm block), and no additional data is added). The usage count of the currently used session key is increased by 1.

[0231] It should be noted that the protocol type field (2 bytes) of the new Ethernet frame header adopts a private definition and still does not occupy the 13th bit of the protocol type field (the Ethernet frame protocol type field has a total of 16 bits from low to high, and the 13th bit is not registered). This bit is used to mark whether session key No. 0 or No. 1 is used.

[0232] The 4-byte decryption index value is the 16 bits before and after the decryption index value in the encryption policy swapped, that is, the destination MAC number | | subtable number.

[0233] In one embodiment, the encryption bridge maintains a 2-byte frame counter for each open port (actually using 15 bits, reset to 0 if the 15-bit counter overflows). Before actual framing, the total length of the encapsulated Ethernet frame is calculated. If the length of the new frame after encapsulation exceeds the MTU of the sending interface, the frame counter of the sending interface is incremented by 1 and assigned to the frame ID field. The highest bit of the frame ID field is set to 1, and the original Ethernet frame is then divided into two data segments for encapsulation and encryption. The two new Ethernet frames after processing have the same encapsulation source MAC, encapsulation destination MAC, decryption index, and frame ID. If the length does not exceed the MTU, the highest bit of the frame information field is set to 0.

[0234] In one embodiment, step 304, in which the second encryption bridge receives the encrypted Ethernet frame, searches a local decryption policy table for a corresponding decryption policy subtable based on the source MAC address of the encrypted Ethernet frame, searches for a corresponding decryption policy item based on a decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypts and decapsulates the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame, includes the following steps:

[0235] The second encryption bridge receives the encrypted Ethernet frame and searches a corresponding decryption policy sub-table in a local decryption policy table according to a source MAC address of the encrypted Ethernet frame;

[0236] When the encrypted Ethernet frame is not framed, the corresponding decryption policy item is searched according to the decryption index of each decryption policy item in the corresponding decryption policy subtable, and the entire encrypted Ethernet frame is checked for ICV integrity using the keyed cryptographic hash algorithm HMAC according to the session key in the corresponding decryption policy item. After the integrity check passes, a symmetric decryption operation is performed on the original Ethernet frame to obtain the original Ethernet frame and forward it;

[0237] When the encrypted Ethernet frame is a frame, the Ethernet frame with the same frame ID is searched in the frame table of the corresponding decryption strategy subtable, and the two frames are decrypted and decapsulated respectively to obtain two original frames, which are spliced ​​into a complete original Ethernet frame and then forwarded.

[0238] It should be noted that the second encryption bridge device node decrypts and decapsulates the inbound Ethernet data frame received from the open port, whose destination MAC is the MAC address of the local interface and conforms to the definition of the private protocol type:

[0239] First, the decryption policy subtable is searched based on the source MAC address (the source MAC is the same as the source MAC in the decryption policy subtable). If the frame is not fragmented, the decryption policy is searched based on the decryption index. If no match is found, the frame is discarded or forwarded according to the default settings. Based on the decryption policy and the 13th bit of the Ethernet frame protocol field, the decryption policy's session key 0 or 1 is selected. The entire Ethernet frame is first subjected to an ICV integrity check using the keyed cryptographic hash algorithm HMAC. If the integrity check passes, the original Ethernet frame is symmetric decrypted; otherwise, it is discarded. The decrypted original Ethernet frame is forwarded according to the normal processing flow of the bridge device.

[0240] If it is a frame, the framing table of the decryption policy subtable is searched for an Ethernet frame with the same framing ID according to the lower 15 bits of the framing ID (to achieve fast framing search, the framing table is an array with 215 elements, each element consists of a framing ID and a corresponding Ethernet frame, and can be directly retrieved according to the framing ID). If there is no frame with the same ID, the frame is added to the framing table. When a frame with the same ID is found, the two frames are subjected to decryption policy search, integrity check and decryption processing according to the method described above, and the two original frames are directly spliced ​​into a complete original Ethernet frame, and forwarded according to the processing flow of the ordinary bridge device.

[0241] This embodiment achieves zero-frame-loss reliable transmission of an encrypted tunnel through a simple and efficient frame segmentation and merging processing method, as well as switching between primary and backup keys, without affecting Layer 2 network services.

[0242] This embodiment uses an encryption bridge that integrates quantum key distribution and a Layer 2 Ethernet frame encryption tunnel to solve the security issues of Layer 2 Ethernet data frames, and realizes a highly secure, lightweight and efficient Ethernet data frame encryption tunnel transmission method. It is mainly aimed at application scenarios of Layer 2 Ethernet frame security encapsulation and encryption that do not have IP addresses and therefore cannot distribute keys and establish secure tunnels through conventional methods. Based on the MAC automatic learning capability of the bridge and the point-to-multipoint information release method of multicast, it automatically learns parameters related to encryption and decryption policies and automatically synthesizes encryption and decryption policies, as well as peer-to-peer negotiation of session keys. Combined with a relatively reasonable and efficient Ethernet tunnel encapsulation format design and processing flow, it realizes a lightweight, highly secure and highly reliable IP-free Layer 2 Ethernet security channel.

[0243] Example 4

[0244] like Figure 5 As shown, the fourth embodiment of the present invention provides an encryption bridge, wherein the encryption bridge serves as a sending end and includes:

[0245] A policy negotiation frame sending module 11 is configured to send a policy negotiation frame to the second encryption bridge, wherein the policy negotiation frame includes a plurality of negotiation policies, each negotiation policy including a source MAC address and a session key component of a corresponding encryption policy subtable, and the second encryption bridge serves as a receiving end encryption bridge;

[0246] A first search module 12 is configured to search a corresponding encryption policy sub-table from a local encryption policy table for a source MAC address of an outbound Ethernet data frame;

[0247] A second search module 13 is configured to search the corresponding encryption policy item from the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame;

[0248] The encryption and encapsulation module 14 is configured to encrypt and encapsulate the Ethernet data frame according to the corresponding encryption policy item, obtain an encrypted Ethernet frame, and send the encrypted Ethernet frame to the second encryption bridge.

[0249] This embodiment utilizes automatic MAC learning of the encryption bridge port, combined with a point-to-multipoint policy distribution method using multicast, to achieve automatic exchange of network parameters and security parameters between members within a security domain. On this basis, it implements automatic generation of security policies and session keys, thus safely and efficiently solving the security policy distribution and management issues of Layer 2 Ethernet devices without IP addresses. Furthermore, by adopting an encrypted tunnel encapsulation method using both internal and external MAC addresses on a Layer 2 Ethernet link, a highly secure and reliable Layer 2 security channel without IP addresses is achieved.

[0250] In one embodiment, the encryption bridge further includes a policy table establishment module for:

[0251] When the sending end encryption bridge is started, a local encryption policy table is established, wherein the encryption policy table includes a plurality of encryption policy sub-tables, the MAC address of each encryption policy sub-table corresponds to a source MAC address of an Ethernet data frame received by the encryption port of the sending end encryption bridge, and each encryption policy sub-table in the initially established encryption policy table includes the MAC address of each encryption policy sub-table and a session key component;

[0252] Based on the local encryption policy table, a corresponding decryption policy table is established, and the decryption policy table includes multiple decryption policy sub-tables. The MAC address of each decryption policy sub-table corresponds to a source MAC address of the Ethernet data frame received by the open port of this encryption bridge. Each decryption policy sub-table in the initially established decryption policy table includes the MAC address of each decryption policy sub-table.

[0253] In one embodiment, when the encryption policy table is established, each encryption policy sub-table therein only contains the sub-table source MAC address and the session key component, and the addition or update of its table entries comes from the key negotiation frame; when the decryption policy table is established, each decryption policy sub-table only contains the sub-table source MAC address, and the addition or update of its table entries comes from the key negotiation frame and the table entries of the encryption policy sub-table.

[0254] Specifically, each encryption policy entry in the encryption policy subtable includes the destination MAC address, the destination MAC number (2 bytes), the encapsulated source MAC address, the encapsulated destination MAC address, the number of the currently used session key, different numbered session keys, and the initialization vector and key usage count corresponding to the session key;

[0255] Each decryption policy item in the decryption policy subtable includes a decryption index, a destination MAC address, an original source MAC address, an original destination MAC address, session keys of different numbers, an initialization vector corresponding to the session key, and a key usage count.

[0256] Among them, the session keys are numbered 0 and 1 respectively, and the relevant data of each numbered session key includes the initialization vector and the key usage count; the destination MAC number in the encryption policy item comes from the source MAC number of the key negotiation frame sent by other encryption network bridges in the same security domain, and is not uniformly numbered in the local encryption policy subtable of this encryption bridge; and the source MAC address in the key negotiation frame comes from the encryption policy subtable number of the encryption bridge that sends the key negotiation frame, that is, it is the same source MAC address as the encryption policy subtable.

[0257] Among them, a decryption policy table is established based on the encryption policy table. The table consists of multiple decryption policy sub-tables. Each decryption policy sub-table is represented by a unique MAC address. The MAC address corresponds to a source MAC address of the Ethernet frame received by the bright port of this bridge (corresponding to the encapsulation destination MAC in the encryption policy item), which is called the sub-table source MAC. Different decryption policy sub-tables have different sub-table source MACs.

[0258] The decryption policy subtable consists of multiple decryption policy items. Each decryption policy item includes a 4-byte decryption index, destination MAC address, original (before encapsulation) source MAC address, original (before encapsulation) destination MAC address, two session keys numbered 0 and 1, the initialization vector of the session key, and the key usage count.

[0259] In one embodiment, the source MAC address of each decryption policy sub-table in the decryption policy table is the encapsulated destination MAC address of each encryption policy sub-table in the corresponding encryption policy table; the destination MAC address, original source MAC address, original destination MAC address, session keys with different numbers and initialization vectors corresponding to the session keys and key usage counts in the decryption policy items in the decryption policy sub-table are from all the encapsulated source MAC addresses, destination MAC addresses, source MAC addresses corresponding to the encryption policy sub-tables, session keys with different numbers and initialization vectors corresponding to the session keys and key usage counts in the encryption policy items of each encryption policy sub-table whose source MAC addresses are the corresponding source MAC addresses of this decryption policy sub-table; the 4-byte decryption index value in the decryption policy item is composed of the 2-byte encryption policy sub-table number and the 2-byte destination MAC number of the corresponding encryption policy item.

[0260] In one embodiment, the policy negotiation frame sending module 11 includes:

[0261] A policy negotiation frame generating unit, configured to generate the policy negotiation frame according to each of the encryption policy sub-tables and their source MAC addresses in the local encryption policy table;

[0262] a policy negotiation frame encryption unit, configured to randomly select a master key from the first secure storage medium, encrypt the portion of the policy negotiation frame excluding the frame header using the master key, calculate a check value of the policy negotiation frame using a keyed hash algorithm, obtain the encrypted policy negotiation frame, and send the encrypted frame to the second encryption bridge;

[0263] The first secure storage medium is integrated into the sending end encryption bridge, and the format of the encrypted policy negotiation frame is:

[0264] 14-byte Ethernet frame header (source MAC + destination MAC + frame type) + 1-byte policy count for this frame + 4-byte master key ID + k*(subtable number + subtable source MAC + n-byte subtable session key component 0 + n-byte subtable session key component 1) + ICV (first integrity check value), where k represents the number of policies sent in this frame.

[0265] In this embodiment, the encryption bridge periodically sends policy negotiation frames to members within the security domain. Each policy negotiation frame consists of multiple negotiation policies. Each policy corresponds to an encryption policy subtable and its source MAC address for the encryption bridge, and its contents are the source MAC address and session key components of that subtable. The entire Ethernet frame is encrypted using a master key randomly selected from a first secure storage medium (the Ethernet frame header is not encrypted), and a first integrity check value (including the frame header) is calculated using a keyed hashing algorithm (HMAC).

[0266] It should be noted that the master key stored in the first secure storage medium is pre-filled with the quantum key distribution system, and each encryption bridge device node in the security domain is pre-filled with a large number of identical master keys and used randomly, which can safely and efficiently solve the problem of identity authentication and distribution of session keys between bridge device nodes with encryption intercommunication requirements.

[0267] In one embodiment, the policy negotiation frame sending module 11 further includes:

[0268] The first judging unit is configured to judge whether the length of the encrypted policy negotiation frame exceeds the MTU of the sending interface;

[0269] a policy negotiation frame sending unit, configured to divide the encrypted policy negotiation frame into multiple frames and then send the frames to the second encryption bridge when the output result of the first judgment unit is yes;

[0270] and for directly sending the encrypted policy negotiation frame to the second encryption bridge when the output result of the first judgment unit is no;

[0271] The type of the frame adopts a private definition, the source MAC address of the frame is the MAC address of the sending interface of the first encryption bridge, and the destination address of the frame is a multicast MAC address adopting a private definition.

[0272] It should be understood that when sending a policy negotiation frame, it is also determined whether the length of the policy negotiation frame exceeds the MTU of the sending interface, and if so, the frame is fragmented.

[0273] In one embodiment, the policy negotiation frame sending unit is further configured to:

[0274] The time interval for sending the encrypted policy negotiation frame is less than or equal to half of the session key usage time threshold, and the same encrypted policy negotiation frame is sent continuously m times each time.

[0275] It should be noted that the time interval for sending the policy negotiation frame is no greater than half of the session key usage time threshold, and the same policy negotiation frame is sent three times consecutively each time.

[0276] In one embodiment, the current frame policy count byte of the policy negotiation frame supports a maximum of 127 policy counts. The highest bit of the byte is added with a flag indicating whether confirmation is required. If the flag is 1, the encryption bridge further includes:

[0277] The confirmation frame receiving module is used to receive the sending confirmation frame returned by the receiving encryption bridge, start the timer queue and add the policy negotiation frame to the queue for periodic retransmission until the policy negotiation frame expires (the session key expires) or all receiving bridges in the security domain have replied with confirmation frames.

[0278] In one embodiment, the encryption bridge further comprises:

[0279] A first filling request module, configured to send a key filling request to the quantum key distribution network;

[0280] The second key acquisition module is used to obtain the master key returned by the quantum key distribution network through the first secure storage medium integrated in the sending-end encryption bridge, establish a master key pool based on the master key, and use a key bitmap to identify whether each master key has been used, wherein each encryption bridge in the same security domain shares a master key with the same master key ID.

[0281] It should be noted that the first secure storage medium in this embodiment is a large-capacity secure storage medium such as a secure TF card or a secure U shield. After receiving the key injection request sent by the encryption bridge, the quantum key distribution network QKD uses the secure storage medium to pre-inject a large number of master keys offline to each encryption bridge device node in the domain. The key format is a 4-byte key ID + n-byte key and an n-byte initialization vector (n is related to the encryption algorithm). Each device in the same security domain shares the same master key identified by the same key ID, establishes a master key pool, and uses a key bitmap to indicate whether the key has been used.

[0282] In one embodiment, the encryption bridge further comprises:

[0283] The interface definition module is used to define the Ethernet interface type of the sending end encryption bridge, wherein the interface not connected to other encryption bridges of the same type is defined as a secret port, and the interface connected to other encryption bridges of the same type is defined as an open port.

[0284] It should be noted that the processing of data frames sent and received by the open port is no different from that of general bridge devices. In addition to performing the functions of an ordinary bridge interface, the secret port establishes an encryption policy sub-table for the newly learned source MAC address and starts a timer to regularly clear the encryption policy sub-table corresponding to the source MAC that has not been received from the secret port within a period of time.

[0285] In one embodiment, the encryption encapsulation module 14 includes:

[0286] an encryption and encapsulation unit, configured to encrypt and encapsulate the Ethernet data frame according to the corresponding encryption policy item, so that the frame format is: a new Ethernet frame header + a decryption index + a framing ID + an original Ethernet frame + a second integrity check value, wherein the information of the new Ethernet frame header includes an encapsulation source MAC, an encapsulation destination MAC, and an encapsulation frame protocol type, wherein the second integrity check value is calculated using a keyed hash algorithm HMAC on the entire Ethernet frame using a currently used numbered session key;

[0287] The counting unit is used to mark the number of the adopted session key by using the unregistered bit in the new Ethernet frame header, and add 1 to the usage count of the session key with the current usage number.

[0288] It should be noted that the sending end encryption bridge device node receives the outbound Ethernet data frame from the encrypted port and forwards it from the open port. It first searches the local corresponding encryption policy subtable based on the source MAC of the outbound Ethernet data frame (that is, the source MAC of the Ethernet data frame is the same as the source MAC of the encryption policy subtable), and then searches the corresponding encryption policy item from the corresponding encryption policy subtable based on the destination MAC of the Ethernet data frame. If the corresponding encryption policy item is not hit, it is discarded or forwarded in plain text according to the default setting. If the corresponding encryption policy item is found, the Ethernet data frame is encrypted and encapsulated according to the encryption policy item.

[0289] It should be noted that other embodiments or implementation methods of the encryption bridge of the present invention can refer to the above-mentioned method embodiment 1, which will not be repeated here.

[0290] Example 5

[0291] like Figure 6 As shown, the fifth embodiment of the present invention provides an encryption bridge, which serves as a receiving end and includes:

[0292] The policy negotiation frame receiving module 21 is used to receive the policy negotiation frame sent by the first encryption bridge, where the first encryption bridge and the receiving end encryption bridge are in the same security domain;

[0293] A policy refresh module 22 is configured to refresh each encryption policy sub-table in its local encryption policy table and each decryption policy sub-table in its local decryption policy table based on each negotiation policy in the policy negotiation frame;

[0294] An encrypted Ethernet frame receiving module 23 is configured to receive an encrypted Ethernet frame sent by the first encryption bridge, wherein the encrypted Ethernet frame is obtained by encrypting and encapsulating an outbound Ethernet data frame by the sending end encryption bridge based on its local corresponding encryption policy item;

[0295] The decryption and decapsulation module 24 is used to search the corresponding decryption policy subtable from its local decryption policy table according to the source MAC address of the encrypted Ethernet frame, search the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypt and decapsulate the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame.

[0296] It should be noted that, in this embodiment, the receiving encryption bridge first searches the local decryption policy table for the corresponding decryption policy subtable based on the source MAC address of the encrypted Ethernet frame, and then searches the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and uses the decryption policy item to decrypt and decapsulate the encrypted Ethernet frame. By utilizing the MAC automatic learning of the encryption bridge port and combining the point-to-multipoint policy distribution method of multicast, the automatic exchange of network parameters and security parameters between members in the security domain is realized, and on this basis, the automatic generation of security policies and session keys is realized, which safely and efficiently solves the security policy distribution and management problems of Layer 2 Ethernet devices without IP addresses; and by adopting the decryption tunnel decapsulation method of internal and external MAC addresses in the Layer 2 Ethernet link, a highly secure and reliable Layer 2 security channel without IP is realized.

[0297] In one embodiment, the encryption bridge further includes a policy table establishment module for:

[0298] When the encryption bridge is started, a local encryption policy table is established, wherein the encryption policy table includes a plurality of encryption policy sub-tables, the MAC address of each encryption policy sub-table corresponds to a source MAC address of an Ethernet data frame received by the encryption port of the sending end encryption bridge, and each encryption policy sub-table in the initially established encryption policy table includes the MAC address of each encryption policy sub-table and a session key component;

[0299] Based on the local encryption policy table, a corresponding decryption policy table is established, and the decryption policy table includes multiple decryption policy sub-tables. The MAC address of each decryption policy sub-table corresponds to a source MAC address of the Ethernet data frame received by the open port of this encryption bridge. Each decryption policy sub-table in the initially established decryption policy table includes the MAC address of each decryption policy sub-table.

[0300] In one embodiment, when the encryption policy table is established, each encryption policy sub-table therein only contains the sub-table source MAC address and the session key component, and the addition or update of its table entries comes from the key negotiation frame; when the decryption policy table is established, each decryption policy sub-table only contains the sub-table source MAC address, and the addition or update of its table entries comes from the key negotiation frame and the table entries of the encryption policy sub-table.

[0301] Specifically, each encryption policy entry in the encryption policy subtable includes the destination MAC address, the destination MAC number (2 bytes), the encapsulated source MAC address, the encapsulated destination MAC address, the number of the currently used session key, different numbered session keys, and the initialization vector and key usage count corresponding to the session key;

[0302] Each decryption policy item in the decryption policy subtable includes a decryption index, a destination MAC address, an original source MAC address, an original destination MAC address, session keys of different numbers, an initialization vector corresponding to the session key, and a key usage count.

[0303] Among them, the session keys are numbered 0 and 1 respectively, and the relevant data of each numbered session key includes the initialization vector and the key usage count; the destination MAC number in the encryption policy item comes from the source MAC number of the key negotiation frame sent by other encryption network bridges in the same security domain, and is not uniformly numbered in the local encryption policy subtable of this encryption bridge; and the source MAC address in the key negotiation frame comes from the encryption policy subtable number of the encryption bridge that sends the key negotiation frame, that is, it is the same source MAC address as the encryption policy subtable.

[0304] Among them, a decryption policy table is established based on the encryption policy table. The table consists of multiple decryption policy sub-tables. Each decryption policy sub-table is represented by a unique MAC address. The MAC address corresponds to a source MAC address of the Ethernet frame received by the bright port of this bridge (corresponding to the encapsulation destination MAC in the encryption policy item), which is called the sub-table source MAC. Different decryption policy sub-tables have different sub-table source MACs.

[0305] The decryption policy subtable consists of multiple decryption policy items. Each decryption policy item includes a 4-byte decryption index, destination MAC address, original (before encapsulation) source MAC address, original (before encapsulation) destination MAC address, two session keys numbered 0 and 1, the initialization vector of the session key, and the key usage count.

[0306] In one embodiment, the source MAC address of each decryption policy sub-table in the decryption policy table is the encapsulated destination MAC address of each encryption policy sub-table in the corresponding encryption policy table; the destination MAC address, original source MAC address, original destination MAC address, session keys with different numbers and initialization vectors corresponding to the session keys and key usage counts in the decryption policy items in the decryption policy sub-table are from all the encapsulated source MAC addresses, destination MAC addresses, source MAC addresses corresponding to the encryption policy sub-tables, session keys with different numbers and initialization vectors corresponding to the session keys and key usage counts in the encryption policy items of each encryption policy sub-table whose source MAC addresses are the corresponding source MAC addresses of this decryption policy sub-table; the 4-byte decryption index value in the decryption policy item is composed of the 2-byte encryption policy sub-table number and the 2-byte destination MAC number of the corresponding encryption policy item.

[0307] In one embodiment, the encryption bridge further includes a key injection module configured to:

[0308] Send a key injection request to the quantum key distribution network;

[0309] The master key returned by the quantum key distribution network is obtained through the second secure storage medium integrated in the receiving-end encryption bridge, and a master key pool is established based on the master key. A key bitmap is used to identify whether each master key has been used, where each encryption bridge in the same security domain shares a master key with the same master key ID.

[0310] In one embodiment, when the first encryption bridge sends a negotiation policy frame encrypted using a master key, the receiving encryption bridge first selects a master key corresponding to the master key ID from its own integrated second secure storage medium, performs an integrity check on the encrypted negotiation policy frame, and decrypts it to obtain a negotiation policy frame.

[0311] It should be noted that if the integrity check fails, the data transmission process will be terminated directly.

[0312] In this embodiment, the second secure storage medium stores a large number of master keys pre-filled by the quantum key distribution network. The second secure storage medium can use a large-capacity secure storage medium such as a secure TF card or a secure U shield. The quantum key distribution network uses the secure storage medium to pre-fill a large number of master keys offline to each encryption bridge device node in the domain. The key format is a 4-byte key ID + n-byte key and an n-byte initialization vector (n is related to the encryption algorithm). Each encryption bridge device in the same security domain shares the same master key identified by the same key ID.

[0313] This embodiment divides the security domain and pre-fills a large number of identical master keys for each device node in the security domain and uses them randomly, thereby safely and efficiently solving the problem of identity authentication and distribution of session keys between bridge device nodes with encryption intercommunication requirements.

[0314] In one embodiment, the policy refresh module 22 includes:

[0315] An encryption policy refresh unit is used to add or update an encryption policy item in all local encryption policy subtables of the second encryption bridge based on each negotiation policy in the policy negotiation frame, and the encryption policy items are numbered incrementally starting from 1, wherein the destination MAC address of the encryption policy item is set to the source MAC of the encryption policy subtable in the negotiation policy, the destination MAC number of the encryption policy item is set to the number of the encryption policy subtable in the negotiation policy, the encapsulation source MAC address and the encapsulation destination MAC address of the encryption policy item are respectively set to the MAC address of the interface on which the second encryption bridge receives the policy negotiation frame and the source MAC address of the policy negotiation frame, and the session key of the encryption policy item is respectively formed by the exclusive OR value of the session key component of the encryption policy subtable corresponding to the same number and the session key component of the negotiation policy;

[0316] The decryption policy refreshing unit is configured to add or update a decryption policy item in all local decryption policy sub-tables of the second encryption bridge corresponding to each encryption policy item generated by the negotiation policy.

[0317] It should be noted that for each negotiation policy in the policy negotiation frame, an encryption policy item is added to all encryption policy subtables of the encryption bridge that receives the policy negotiation frame. The encryption policy number increases from 1, and the destination MAC address of the encryption policy is set to the subtable source MAC in the negotiation policy. If there is a policy item with the same destination MAC in the encryption policy subtable, the policy item will be updated. The destination MAC is the primary key of the encryption policy subtable and is unique.

[0318] Furthermore, in the encryption policy refresh unit, the session keys include session keys numbered 0 and 1, and the two numbered session keys serve as primary and backup for each other. The session keys 0 and 1 in the updated or added encryption policy items are respectively the exclusive OR values ​​of the session key component of the encryption policy subtable with the same number and the session key component of the negotiated policy. The initialization vectors 0 and 1 generated by the session key 0 or 1 are generated by the following formula:

[0319] Initialization vector = E(session key, (source MAC of encryption policy subtable | source MAC of negotiation policy subtable) || (encapsulation source MAC of encryption policy | encapsulation destination MAC of encryption policy) || padding)

[0320] In the above formula, E(K, D) represents the symmetric encryption operation on the data D using the key K, and padding is the padding data (the encrypted data length is padded to the encryption algorithm block length, and the padding method is to repeatedly fill in the 10 numbers from 0 to 9 until the length requirement is met).

[0321] Initially, session key 0 and initialization vector 0 are used, and a timer and usage count are enabled for the currently used key. When the timer or usage count for an encryption policy in the encryption policy subtable exceeds a threshold, the key numbers currently used by all encryption policies in the subtable are switched, and the key components corresponding to the switched key numbers are updated using random numbers collected in real time. Because key numbers are switched uniformly within the subtable, all encryption policies in the subtable use the same key number at the same time.

[0322] Furthermore, in the decryption policy refresh unit, if the encapsulation destination MAC in the encryption policy item does not have a corresponding sub-table source MAC in the decryption policy sub-table, a new decryption policy sub-table is created with the source MAC being the encapsulation destination MAC in the encryption policy. The decryption policies corresponding to encryption policies with the same encapsulation destination MAC (which can be located in different encryption policy sub-tables, or the same encryption policy sub-table can have multiple encryption policies with the same encapsulation destination MAC) are located in the same decryption policy sub-table (the sub-table source MAC being the encapsulation destination MAC).

[0323] In one embodiment, the encryption bridge further includes an interface definition module for:

[0324] Define the type of each Ethernet interface of the encryption bridge: the interface not connected to other encryption bridges of the same type is defined as a encrypted port, and the interface connected to other encryption bridges of the same type is defined as an open port.

[0325] Among them, the processing of data frames sent and received by the open port is no different from that of general bridge devices; in addition to performing the functions of an ordinary bridge interface, the secret port establishes an encryption policy sub-table for the newly learned source MAC address, and starts a timer to regularly clear the encryption policy sub-table corresponding to the source MAC that has not been received from the secret port within a period of time.

[0326] In one embodiment, the decryption and decapsulation module 24 includes:

[0327] A decryption policy search unit, configured to search a corresponding decryption policy sub-table from a local decryption policy table according to the source MAC address of the encrypted Ethernet frame;

[0328] It should be noted that the receiving end encryption bridge device node decrypts and decapsulates the inbound Ethernet data frame received from the open port, whose destination MAC is the MAC address of this interface and conforms to the private protocol type definition. First, it searches the local decryption policy table for the corresponding decryption policy subtable based on the source MAC address of the encrypted Ethernet frame.

[0329] a whole-frame decryption unit, which, when the encrypted Ethernet frame is not framed, searches for a corresponding decryption policy item according to the decryption index of each decryption policy item in the corresponding decryption policy subtable, performs an ICV integrity check on the entire encrypted Ethernet frame using a keyed cryptographic hash algorithm HMAC based on the session key in the corresponding decryption policy item, and performs a symmetric decryption operation on the original Ethernet frame after the integrity check passes, obtains the original Ethernet frame, and forwards it;

[0330] If the frame is not fragmented, the corresponding decryption policy item is searched based on the decryption index. If no corresponding decryption policy item is found, the encrypted Ethernet frame is discarded or forwarded according to the default settings. If a corresponding decryption policy item is found, the decryption policy's session key 0 or 1 is selected based on bit 13 of the Ethernet frame protocol field. The entire Ethernet frame is first subjected to an ICV integrity check using the keyed cryptographic hash algorithm HMAC. If the integrity check passes, the original Ethernet frame is symmetric decrypted. If the integrity check fails, the frame is discarded. The decrypted original Ethernet frame is then forwarded according to the normal bridge device processing flow.

[0331] The framing decryption unit is used to search for an Ethernet frame with the same framing ID in the framing table of the corresponding decryption strategy subtable when the encrypted Ethernet frame is a framing frame, decrypt and decapsulate the two frames respectively, obtain two original frames, splice them into a complete original Ethernet frame, and then forward them.

[0332] It should be noted that if the received encrypted Ethernet frame is a fragmented frame, the decryption policy subtable's fragmented frame table is searched for an Ethernet frame with the same fragmented frame ID based on the lower 15 bits of the fragmented frame ID. If no fragmented frame with the same ID exists, the frame is added to the fragmented frame table. If a fragmented frame with the same ID is found, the two fragmented frames are subjected to a decryption policy search, integrity check, and decryption respectively. The two original fragmented frames are then directly concatenated into a complete original Ethernet frame and forwarded according to the processing flow of a standard network bridge device.

[0333] It should be noted that other embodiments or implementation methods of the encryption bridge of the present invention can refer to the above-mentioned method embodiment 2, which will not be repeated here.

[0334] Example 6

[0335] like Figure 7 As shown, the sixth embodiment of the present invention proposes an Ethernet link self-organized encryption and decryption tunnel implementation system using quantum key distribution, the system includes a first encryption bridge 1, a second encryption bridge 2, a quantum key distribution system 3 and a management and control platform 4, the first encryption bridge 1 and the second encryption bridge 2 are connected, the first encryption bridge 1 and the second encryption bridge 2 are both connected to the management and control platform 4, the first encryption bridge 1, the second encryption bridge 2 and the management and control platform 4 are respectively connected to the quantum key distribution system 3, wherein:

[0336] The management and control platform 4 is used to provide the correspondence between the first encryption bridge 1, the second encryption bridge 2, the key agent, and the quantum network node, and to divide the security domain, and provide registration and identity binding services for the encryption bridge;

[0337] The quantum key distribution system 3 is used to provide agent functions for master key filling and online master key distribution;

[0338] The first encryption bridge 1 is configured to send a policy negotiation frame to the second encryption bridge 2, wherein the policy negotiation frame includes a plurality of negotiation policies, and the content of each negotiation policy is a source MAC address and a session key component of a corresponding encryption policy subtable;

[0339] After receiving the policy negotiation frame, the second encryption bridge 2 is configured to refresh each encryption policy sub-table in the local encryption policy table of the second encryption bridge and each decryption policy sub-table in the decryption policy table based on each negotiation policy in the policy negotiation frame;

[0340] The first encryption bridge 1 is configured to search a corresponding encryption policy subtable in a local encryption policy table according to the source MAC address of the outbound Ethernet data frame, search a corresponding encryption policy item in the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame, and encrypt and encapsulate the Ethernet data frame according to the corresponding encryption policy item to obtain an encrypted Ethernet frame and send it to the second encryption bridge;

[0341] After the second encryption bridge 2 receives the encrypted Ethernet frame, it is used to search the corresponding decryption policy subtable from the local decryption policy table according to the source MAC address of the encrypted Ethernet frame, search for the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypt and decapsulate the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame.

[0342] This embodiment utilizes the automatic MAC learning of the bridge port, combined with the point-to-multipoint policy distribution method of multicast, to realize the automatic exchange of network parameters and security parameters between members in the security domain. On this basis, it realizes the automatic generation of security policies and session keys, and safely and efficiently solves the security policy distribution and management problems of Layer 2 Ethernet devices without IP addresses. By adopting the encrypted tunnel encapsulation method of internal and external MAC addresses in the Layer 2 Ethernet link, a highly secure and reliable IP-free Layer 2 security channel is realized.

[0343] It should be noted that the encryption bridge in this embodiment is used to perform tunnel encapsulation and decapsulation and encryption and decryption processing on user Ethernet data frames transmitted through the bridge, and is composed of modules such as data encryption and decryption processing, frame processing module, policy management module, key update, and key injection;

[0344] Management and control platform: used to provide the corresponding relationship between encryption bridges, key agents, and quantum network nodes, divide security domains, and provide registration and identity binding services for encryption bridges;

[0345] Key agent: used to provide key injection and online key distribution agent functions when the nodes of the quantum key distribution network cannot directly provide key injection and online key distribution services;

[0346] Quantum key distribution network: includes quantum network nodes and quantum network link control center, realizing quantum key generation and online distribution, quantum key relay, quantum key provision and other services;

[0347] Quantum network node: stores generated quantum keys, receives key requests from key agents, provides keys to key agents, or directly provides key injection and online key distribution services;

[0348] Quantum network link control center: can establish quantum key distribution and relay links between nodes according to quantum network node ID.

[0349] It should be noted that the key distribution device used in this embodiment includes but is based on but not limited to the QKD key distribution network. The key pre-filling function involved in this embodiment can be implemented using any symmetric key management system and device. The symmetric encryption algorithm and cryptographic hash algorithm involved in this embodiment can use any algorithm that complies with national cryptographic management regulations.

[0350] In one embodiment, if Figure 8 As shown, the encryption bridge includes a clear port, a secret port, a data encryption and decryption processing module, a frame processing module, a policy management module, a key update module, and a key injection module. The key injection module is connected to a secure storage medium; wherein:

[0351] An interface not connected to another encryption bridge of the same type is defined as a secure port, while an interface connected to another encryption bridge of the same type is defined as an open port. The data frames sent and received by an open port are processed in the same way as those of a general bridge device. In addition to performing the functions of a normal bridge interface, a secure port establishes an encryption policy subtable for newly learned source MAC addresses and starts a timer to periodically clear the encryption policy subtable corresponding to source MAC addresses that have not been received from the secure port within a period of time.

[0352] a frame processing module, configured to generate a policy negotiation frame, the policy negotiation frame including a plurality of negotiation policies, the content of each negotiation policy being a source MAC address and a session key component of a corresponding encryption policy subtable; or to refresh each encryption policy subtable in the encryption policy table and each decryption policy subtable in the decryption policy table of the second encryption bridge based on each negotiation policy in the policy negotiation frame;

[0353] A policy management module is used to manage the refresh of the policy table based on the policy negotiation frame. The policy table includes an encryption policy table and a decryption policy table.

[0354] a data encryption and decryption processing module, configured to search a corresponding encryption policy subtable from a local encryption policy table according to the source MAC address of an outbound Ethernet data frame, search a corresponding encryption policy item from the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame, encrypt and encapsulate the Ethernet data frame according to the corresponding encryption policy item, obtain an encrypted Ethernet frame, and send the encrypted Ethernet frame to the second encryption bridge; or receive the encrypted Ethernet frame, search a corresponding decryption policy subtable from a local decryption policy table according to the source MAC address of the encrypted Ethernet frame, search a corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypt and decapsulate the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame;

[0355] The key injection module is connected to a secure storage medium and is used to obtain the master key pre-filled in the quantum key distribution network through the secure storage medium and build a master key pool based on the master key;

[0356] The key update module is used to switch the key numbers currently used by all encryption policies in the encryption policy subtable when the key switching condition is met, and update the key components corresponding to the switched key numbers by collecting random numbers in real time.

[0357] It should be noted that the session key includes two types of session keys numbered 0 and 1, which serve as primary and backup for each other. By enabling the timer and usage count for the currently used key, when the timer or usage count of an encryption policy item in the encryption policy subtable exceeds the threshold, the session key with the currently used number will be switched.

[0358] The following is based on Figure 9 The workflow of the Ethernet link self-organizing encryption and decryption tunnel implementation system using quantum key distribution proposed in this embodiment is described as follows:

[0359] (1) Define the security domain, and use a large-capacity secure storage medium such as a secure TF card or a secure U-shield to pre-inject a large number of master keys offline into each encryption bridge device node in the domain through the quantum key distribution network QKD. The key format is a 4-byte key ID + n-byte key and n-byte initialization vector (n is related to the encryption algorithm). Each device in the same security domain shares the same master key identified by the same key ID.

[0360] (2) Inject the pre-filled master key into the encryption bridge device node in the domain, establish a master key pool, and use the key bitmap to indicate whether the key has been used.

[0361] (3) Define the type of each Ethernet interface of the encryption bridge: interfaces not connected to other encryption bridges of the same type are defined as encrypted ports, and interfaces connected to other encryption bridges of the same type are defined as open ports. The processing of data frames sent and received by open ports is no different from that of ordinary bridge devices; in addition to performing the functions of ordinary bridge interfaces, encrypted ports establish encryption policy subtables for newly learned source MAC addresses and start a timer to periodically clear the encryption policy subtables corresponding to source MAC addresses that have not been received from the encrypted ports within a period of time.

[0362] (4) When the encryption bridge is started, an encryption policy table is established based on the MAC learning mechanism of a general bridge. This table consists of multiple encryption policy subtables. Each subtable is represented by a unique MAC address. This MAC address corresponds to a source MAC address of the Ethernet frame received by the encryption port of this bridge, which is called the subtable source MAC. Different encryption policy subtables have different subtable source MACs. The encryption policy subtable contains two session key components, numbered 0 and 1, which are fresh random numbers regularly collected and updated from the random number generator built into the device. The encryption policy subtable consists of multiple encryption policy items. Each policy item consists of the destination MAC address, the destination MAC number (2 bytes), the encapsulated source MAC address, the encapsulated destination MAC address, the currently used key number, and two session key related data (session key and initialization vector, key usage count) numbered 0 and 1 respectively. Among them, the destination MAC number comes from the source MAC number in the key negotiation frame received from other encryption bridges and is not uniformly numbered in this subtable. The source MAC number in the key negotiation frame comes from the encryption policy subtable number of the encryption bridge that sent the negotiation frame (the same source MAC as the encryption policy subtable).

[0363] When the encryption policy subtable is created, only the subtable source MAC address and session key components exist, and its table entries come from the key negotiation frame.

[0364] When an encryption bridge forwards an Ethernet frame received from a secure port, it searches the encryption policy subtable based on the source MAC address. It then searches the encryption policy entry based on the destination MAC address and encrypts the Ethernet frame using the session key with the currently used key number. Encryption policy subtables are uniformly numbered starting at 1, occupying two bytes and unique within the encryption bridge.

[0365] (5) A decryption policy table is established based on the encryption policy table. This table consists of multiple decryption policy sub-tables. Each sub-table is represented by a unique MAC address. This MAC address corresponds to a source MAC address of the Ethernet frame received by the active port of this bridge (corresponding to the encapsulated destination MAC in the encryption policy). This is called the sub-table source MAC. Different decryption policy sub-tables have different sub-table source MACs. The decryption policy sub-table consists of multiple decryption policy items. Each decryption policy item consists of a 4-byte decryption index, a destination MAC address, the original (before encapsulation) source MAC address, the original (before encapsulation) destination MAC address, and two session keys numbered 0 and 1 (and the initialization vector and key usage count). The relationship between the encryption policy table (and sub-tables, table items) and the decryption policy (and sub-tables, table items) is as follows: the source MAC corresponding to each decryption policy sub-table comes from the encapsulated destination MAC in the encryption policy sub-table, the destination MAC address, original (before encapsulation) source MAC address, original (before encapsulation) destination MAC address, and two session keys numbered 0 and 1 respectively in the decryption policy item in the decryption policy sub-table come from all the encapsulated source MAC addresses, destination MAC addresses, encryption policy sub-table corresponding source MAC addresses, and two session keys numbered 0 and 1 respectively in the encryption policy items of all encryption policy sub-tables whose encapsulated destination MAC is the source MAC of this decryption policy sub-table. The 4-byte decryption index value of the decryption policy item consists of the 2-byte encryption policy sub-table number and the 2-byte destination MAC number of the corresponding encryption policy item.

[0366] When the decryption policy subtable is created, only the subtable source MAC address exists. Its entries come from the key negotiation frame and the encryption policy subtable entries.

[0367] (6) The encryption bridge periodically sends policy negotiation frames to members within the security domain. Each policy negotiation frame consists of multiple negotiation policies. Each policy corresponds to an encryption policy subtable and its source MAC address of the encryption bridge. The content is the source MAC address and session key component of the subtable. The entire Ethernet frame is encrypted using a randomly selected master key (the Ethernet frame header is not encrypted) and the checksum (including the frame header) is calculated using the keyed hash algorithm HMAC. The frame format is:

[0368] 14-byte Ethernet frame header (source MAC + destination MAC + frame type) + 1-byte frame policy count / confirmation tag + 4-byte master key ID + k*(subtable number + subtable source MAC + n-byte subtable session key component 0 + n-byte subtable session key component 1) + ICV (integrity check value)

[0369] The length of the entire frame cannot exceed the MTU of the interface. If it exceeds the MTU, it will be divided into multiple frames for transmission. The frame type adopts a private definition. The source MAC of the frame is the MAC of the bridge sending interface, and the destination MAC of the frame also adopts a privately defined multicast MAC address. The time interval for sending policy negotiation frames shall not exceed half of the session key usage time threshold, and the same policy negotiation frame shall be sent three times in succession each time. The policy count byte of this frame supports up to 127 policy counts. The highest bit of this byte is whether a confirmation mark is required. If the mark is 1, the recipient needs to send a confirmation frame. If the confirmation mark bit is 1, the sending bridge starts the timer queue and adds the frame to the queue for periodic retransmission until the frame expires (the session key expires) or all bridges in the security domain have replied with a confirmation frame.

[0370] (7) After receiving the policy negotiation frame, the encryption bridge takes out the master key according to the master key ID to perform integrity check and decrypt the frame. For each negotiation policy in the policy negotiation frame, an encryption policy item is added to all encryption policy subtables of the encryption bridge that receives the frame. The encryption policy number increases from 1. The destination MAC address of the encryption policy is set to the source MAC of the subtable in the negotiation policy (if there is already a policy item with the same destination MAC in the encryption policy subtable, the policy item is updated. The destination MAC is the primary key of the encryption policy subtable and is unique). The destination MAC number of the encryption policy is set to the subtable number in the negotiation policy. The encapsulation source MAC address and encapsulation destination MAC address of the encryption policy are set to the MAC address of the interface that receives the policy negotiation frame and the source MAC address of the policy negotiation frame respectively. The session keys 0 and 1 of the encryption policy are the exclusive OR values ​​of the session key component of the encryption policy subtable with the same number and the session key component of the negotiation policy respectively. The initialization vector is generated by the following formula:

[0371] Initialization vector = E(session key, (source MAC of encryption policy subtable | source MAC of negotiation policy subtable) || (encapsulation source MAC of encryption policy | encapsulation destination MAC of encryption policy) || padding)

[0372] In the above formula, E(K, D) indicates that the data D is symmetric encrypted using the key K, and padding is padding data (the length of the encrypted data is padded to the length of the cryptographic algorithm block, and the padding method is to repeat the 10 numbers from 0 to 9 until the length requirement is met). Session keys 0 or 1 generate initialization vectors 0 to 1 respectively. Initially, session key 0 and initialization vector 0 are used, and the timer and usage count are enabled for the currently used key. When the timer or usage count of an encryption policy in the encryption policy subtable exceeds the threshold, the key number currently used by all encryption policies in the subtable is switched, and the key component corresponding to the switched key number is updated by collecting random numbers in real time. Because the key number in the subtable is switched uniformly, all encryption policies in the subtable use the same key number at the same time.

[0373] (8) For each encryption policy generated by the negotiation policy of the policy negotiation frame, add or update a decryption policy according to the method in S4. If the encapsulation destination MAC in the encryption policy does not have a corresponding decryption policy subtable (subtable source MAC), then a new decryption policy subtable is created with the source MAC being the encapsulation destination MAC in the encryption policy. The decryption policies corresponding to encryption policies with the same encapsulation destination MAC (which can be located in different encryption policy subtables, and the same encryption policy subtable can have multiple encryption policies with the same encapsulation destination MAC) are located in the same decryption policy subtable (the subtable source MAC is the encapsulation destination MAC).

[0374] (9) The encryption bridge device node encrypts and encapsulates the outbound Ethernet data frames received from the encrypted port and forwarded from the open port. First, the encryption policy subtable is searched based on the source MAC (the source MAC is the same as the source MAC in the encryption policy subtable), and then the encryption policy is searched based on the destination MAC. If there is no match, it is discarded or forwarded in plain text according to the default settings. The Ethernet frame is encrypted and encapsulated according to the encryption policy. The specific frame format is as follows:

[0375] 14-byte new Ethernet frame header (encapsulated source MAC + encapsulated destination MAC + encapsulated frame protocol type) + 4-byte decryption index + 2-byte framing ID + original Ethernet frame + ICV (integrity check value)

[0376] The currently used session key is used to calculate the ICV integrity check value for the entire Ethernet frame (including the new Ethernet frame header) using the keyed hash algorithm HMAC. The original Ethernet frame is symmetric encrypted (encryption mode is CBC (integer multiples of the algorithm block) + CFB (the remainder beyond the integer multiples of the algorithm block), without adding any additional data). The usage count of the currently used session key is incremented by 1.

[0377] The protocol type field (2 bytes) in the new Ethernet frame header uses a private definition and still does not occupy the 13th bit of the protocol type field (the Ethernet frame protocol type field has 16 bits from low to high, and the 13th bit is unregistered). This bit is used to indicate whether session key 0 or 1 is used. The 4-byte decryption index value is the 16 bits before and after the decryption index value in the encryption policy swapped. That is, the time transmission value is the destination MAC number || subtable number.

[0378] The encryption bridge maintains a 2-byte framing counter for each open port (actually using 15 bits, reset to 0 if the 15-bit counter overflows). Before actual framing, the total length of the encapsulated Ethernet frame is calculated. If the length of the new frame after encapsulation exceeds the MTU of the sending interface, the framing counter of the sending interface is incremented by 1 and assigned to the framing ID field. The highest bit of the framing ID field is set to 1, and the original Ethernet frame is then divided into two segments for encapsulation and encryption. The two new Ethernet frames have the same encapsulation source MAC, encapsulation destination MAC, decryption index, and framing ID. If the length does not exceed the MTU, the highest bit of the framing information field is set to 0.

[0379] (10) The receiving end encryption bridge device node of the encrypted Ethernet frame decrypts and decapsulates the inbound Ethernet data frame received from the open port, whose destination MAC is the MAC address of this interface and complies with the definition of the private protocol type.

[0380] First, the decryption policy subtable is searched based on the source MAC address (the source MAC is the same as the source MAC in the decryption policy subtable). If the frame is not fragmented, the decryption policy is searched based on the decryption index. If no match is found, the frame is discarded or forwarded according to the default settings. Based on the decryption policy and the 13th bit of the Ethernet frame protocol field, the decryption policy's session key 0 or 1 is selected. The entire Ethernet frame is first subjected to an ICV integrity check using the keyed cryptographic hash algorithm HMAC. If the integrity check passes, the original Ethernet frame is symmetric decrypted; otherwise, it is discarded. The decrypted original Ethernet frame is forwarded according to the normal processing flow of the bridge device.

[0381] If it is a frame, the framing table in the decryption policy subtable is searched for an Ethernet frame with the same frame ID based on the lower 15 bits of the frame ID. (To achieve fast frame search, the framing table is an array with 215 elements, each element consisting of a frame ID and a corresponding Ethernet frame, and can be directly searched based on the frame ID.) If there is no frame with the same ID, the frame is added to the framing table. If a frame with the same ID is found, the two frames are subjected to decryption policy search, integrity check, and decryption processing as described above. The two original frames are then directly spliced ​​into a complete original Ethernet frame and forwarded according to the processing flow of a normal network bridge device.

[0382] This embodiment uses a large-capacity master key generated by a quantum key distribution system in a special bridge device - an encryption bridge, and adopts a self-learning and self-organizing strategy for generation and release, key distribution, and encryption tunnel establishment to achieve a highly secure, efficient, and reliable Ethernet link encryption tunnel transmission method.

[0383] It should be noted that the logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device), or in conjunction with such instruction execution system, apparatus, or device. For the purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transmit a program for use by an instruction execution system, apparatus, or device, or in conjunction with such instruction execution system, apparatus, or device. More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection portion having one or more wires (electronic device), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable compact disc read-only memory (CDROM). Furthermore, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing it in another suitable manner if necessary, and then storing it in a computer memory.

[0384] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0385] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0386] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0387] Although the embodiments of the present invention have been shown and described above, it will be understood that the above embodiments are illustrative and are not to be construed as limitations on the present invention. A person skilled in the art may change, modify, replace and modify the above embodiments within the scope of the present invention.

Claims

1. A method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution, characterized in that: Applied to a sending-end encryption bridge, the method includes: Sending a policy negotiation frame to the second encryption bridge, wherein the policy negotiation frame includes a plurality of negotiation policies, and the content of each negotiation policy is a source MAC address and a session key component of a corresponding encryption policy subtable; Search the corresponding encryption policy subtable in the local encryption policy table based on the source MAC address of the outbound Ethernet data frame; Search the corresponding encryption policy item from the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame; The Ethernet data frame is encrypted and encapsulated according to the corresponding encryption policy item to obtain an encrypted Ethernet frame and send it to the second encryption bridge.

2. The method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution according to claim 1, wherein: Before sending the policy negotiation frame to the second encryption bridge, the method further includes: When the sending end encryption bridge is started, a local encryption policy table is established, wherein the encryption policy table includes a plurality of encryption policy sub-tables, the MAC address of each encryption policy sub-table corresponds to a source MAC address of an Ethernet data frame received by the encryption port of the sending end encryption bridge, and each encryption policy sub-table in the initially established encryption policy table includes the MAC address of each encryption policy sub-table and a session key component; Based on the local encryption policy table, a corresponding decryption policy table is established, and the decryption policy table includes multiple decryption policy sub-tables. The MAC address of each decryption policy sub-table corresponds to a source MAC address of the Ethernet data frame received by the open port of this encryption bridge. Each decryption policy sub-table in the initially established decryption policy table includes the MAC address of each decryption policy sub-table.

3. The method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution according to claim 2, wherein: Each encryption policy entry in the encryption policy subtable includes the destination MAC address, destination MAC number, encapsulation source MAC address, encapsulation destination MAC address, the number of the currently used session key, different numbered session keys, and the initialization vector and key usage count corresponding to the session key; Each decryption policy entry in the decryption policy subtable includes a decryption index, a destination MAC address, an original source MAC address, an original destination MAC address, a session key with a different number, an initialization vector corresponding to the session key, and a key usage count; Among them, the source MAC address of each decryption policy sub-table in the decryption policy table is the encapsulated destination MAC address of each encryption policy sub-table in the corresponding encryption policy table; the destination MAC address, original source MAC address, original destination MAC address, session keys with different numbers and initialization vectors corresponding to session keys and key usage counts in the decryption policy items in the decryption policy sub-table are from all the encapsulated source MAC addresses, destination MAC addresses, source MAC addresses corresponding to the encryption policy sub-table, session keys with different numbers and initialization vectors corresponding to session keys and key usage counts in the encryption policy items of each encryption policy sub-table whose source MAC address is the corresponding source MAC address of this decryption policy sub-table; the decryption index in the decryption policy item includes the encryption policy sub-table number and destination MAC number of the corresponding encryption policy item.

4. The method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution according to claim 1, wherein: The sending of the policy negotiation frame to the second encryption bridge includes: Generate the policy negotiation frame according to each encryption policy sub-table in the local encryption policy table and its source MAC address; A master key is randomly selected from a first secure storage medium, and the master key is used to encrypt the portion of the policy negotiation frame except the frame header, and a keyed hashing algorithm is used to calculate the check value of the policy negotiation frame to obtain an encrypted policy negotiation frame and send it to the second encryption bridge, wherein the first secure storage medium is integrated in the sending end encryption bridge, and the format of the encrypted policy negotiation frame is: Ethernet frame header + current frame policy count + master key ID + k*(encryption policy subtable number + encryption policy subtable source MAC address + subtable session key component 0 + subtable session key component 1) + first integrity check value, the information of the Ethernet frame header includes the source MAC address, destination MAC address and frame type, and a confirmation mark is added to the highest bit of the byte of the current frame policy count.

5. The method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution according to claim 4, wherein: Sending the encrypted policy negotiation frame to the second encryption bridge includes: When it is determined that the length of the encrypted policy negotiation frame exceeds the MTU of the sending interface, the encrypted policy negotiation frame is divided into multiple frames and then sent to the second encryption bridge; The frame type adopts a private definition, the source MAC address of the frame is the MAC address of the sending interface of the sending end encryption bridge, and the destination address of the frame is a multicast MAC address adopting a private definition.

6. The method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution according to claim 4, wherein: Sending the encrypted policy negotiation frame to the second encryption bridge includes: The time interval for sending the encrypted policy negotiation frame is less than or equal to half of the session key usage time threshold, and the same encrypted policy negotiation frame is sent continuously m times each time.

7. The method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution according to claim 4, wherein: When the confirmation flag is 1, the method further includes: receiving a confirmation frame returned by the second encryption bridge; The timer queue is started and the encryption policy negotiation frame is added to the timer queue and retransmitted periodically until the encryption policy negotiation frame becomes invalid or all the second encryption bridges return confirmation frames.

8. The method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution according to claim 1, wherein: Before sending the policy negotiation frame to the second encryption bridge, the method further includes: Send a key injection request to the quantum key distribution network; The master key returned by the quantum key distribution network is obtained through the first secure storage medium integrated in the sending-end encryption bridge, and a master key pool is established based on the master key. A key bitmap is used to identify whether each master key has been used, where each encryption bridge in the same security domain shares a master key with the same master key ID.

9. The method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution according to claim 1, wherein: Before sending the policy negotiation frame to the second encryption bridge, the method further includes: Defining the Ethernet interface type of the sending end encryption bridge, wherein the interface not connected to other encryption bridges of the same type is defined as a dense port, and the interface connected to other encryption bridges of the same type is defined as an open port; The encrypted port is used to add the source MAC address learned by the port to the local encryption policy sub-table, and to periodically clear the encryption policy sub-table corresponding to the source MAC address not received from the encrypted port within a set time.

10. The method for implementing a self-organized encrypted tunnel over an Ethernet link using quantum key distribution according to claim 1, wherein: The encrypting and encapsulating the Ethernet data frame according to the corresponding encryption policy item to obtain an encrypted Ethernet frame and sending it to the second encryption bridge includes: After encrypting and encapsulating the Ethernet data frame according to the corresponding encryption policy item, the frame format is: a new Ethernet frame header + a decryption index + a framing ID + an original Ethernet frame + a second integrity check value, wherein the information of the new Ethernet frame header includes an encapsulation source MAC, an encapsulation destination MAC, and an encapsulation frame protocol type, wherein the second integrity check value is calculated using a keyed hash algorithm HMAC on the entire Ethernet frame using a currently used numbered session key; The unregistered bit in the new Ethernet frame header is used to mark the serial number of the adopted session key, and the usage count of the currently used serial numbered session key is increased by 1.

11. The method for implementing a self-organizing encrypted tunnel over an Ethernet link using quantum key distribution according to claim 10, wherein: Before sending the encrypted Ethernet frame to the second encryption bridge, the method further includes: Before actual framing, the total length of the encapsulated Ethernet frame is calculated. If the length of the new frame after encapsulation exceeds the MTU of the sending interface, the framing counter of the sending interface is incremented by 1 and assigned to the framing ID field. The highest bit of the framing ID field is set to 1, and the original Ethernet frame is divided into two new Ethernet frame data segments for encapsulation and encryption. The two new Ethernet frames have the same encapsulation source MAC, encapsulation destination MAC, decryption index, and framing ID. If the length of the new frame after encapsulation does not exceed the MTU of the sending interface, the highest bit of the Frame ID field is set to 0.

12. A method for implementing a self-organized decryption tunnel in an Ethernet link using quantum key distribution, characterized in that: Applied to a receiving-end encryption bridge, the method includes: receiving a policy negotiation frame sent by a first encryption bridge, where the first encryption bridge and the receiving-end encryption bridge are in the same security domain; Based on each negotiation policy in the policy negotiation frame, refreshing each encryption policy sub-table in its local encryption policy table and each decryption policy sub-table in its local decryption policy table; receiving an encrypted Ethernet frame sent by the first encryption network bridge, where the encrypted Ethernet frame is obtained by the first encryption network bridge encrypting and encapsulating an outbound Ethernet data frame based on its locally corresponding encryption policy item; According to the source MAC address of the encrypted Ethernet frame, the corresponding decryption policy subtable is searched from its local decryption policy table, the corresponding decryption policy item is searched based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and the encrypted Ethernet frame is decrypted and decapsulated according to the corresponding decryption policy item to obtain the Ethernet data frame.

13. The method for implementing a self-organized decryption tunnel over an Ethernet link using quantum key distribution according to claim 12, wherein: Before receiving the policy negotiation frame sent by the first encryption bridge, the method further includes: When the sending end encryption bridge is started, a local encryption policy table is established, wherein the encryption policy table includes a plurality of encryption policy sub-tables, the MAC address of each encryption policy sub-table corresponds to a source MAC address of an Ethernet data frame received by the encryption port of the sending end encryption bridge, and each encryption policy sub-table in the initially established encryption policy table includes the MAC address of each encryption policy sub-table and a session key component; Based on the local encryption policy table, a corresponding decryption policy table is established, and the decryption policy table includes multiple decryption policy sub-tables. The MAC address of each decryption policy sub-table corresponds to a source MAC address of the Ethernet data frame received by the open port of this encryption bridge. Each decryption policy sub-table in the initially established decryption policy table includes the MAC address of each decryption policy sub-table.

14. The method for implementing a self-organized decryption tunnel over an Ethernet link using quantum key distribution according to claim 13, wherein: Each encryption policy entry in the encryption policy subtable includes the destination MAC address, destination MAC number, encapsulation source MAC address, encapsulation destination MAC address, the number of the currently used session key, different numbered session keys, and the initialization vector and key usage count corresponding to the session key; Each decryption policy entry in the decryption policy subtable includes a decryption index, a destination MAC address, an original source MAC address, an original destination MAC address, a session key with a different number, an initialization vector corresponding to the session key, and a key usage count; Among them, the source MAC address of each decryption policy sub-table in the decryption policy table is the encapsulated destination MAC address of each encryption policy sub-table in the corresponding encryption policy table; the destination MAC address, original source MAC address, original destination MAC address, session keys with different numbers and initialization vectors corresponding to session keys and key usage counts in the decryption policy items in the decryption policy sub-table are from all the encapsulated source MAC addresses, destination MAC addresses, source MAC addresses corresponding to the encryption policy sub-table, session keys with different numbers and initialization vectors corresponding to session keys and key usage counts in the encryption policy items of each encryption policy sub-table whose source MAC address is the corresponding source MAC address of this decryption policy sub-table; the decryption index in the decryption policy item includes the encryption policy sub-table number and destination MAC number of the corresponding encryption policy item.

15. The method for implementing a self-organized decryption tunnel over an Ethernet link using quantum key distribution according to claim 12, wherein: The refreshing of each encryption policy sub-table in the local encryption policy table and each decryption policy sub-table in the decryption policy table based on each negotiation policy in the policy negotiation frame includes: Based on each negotiation policy in the policy negotiation frame, an encryption policy item is added or updated in all local encryption policy subtables of the receiving end encryption bridge, and the encryption policy items are numbered incrementally starting from 1, wherein the destination MAC address of the encryption policy item is set to the source MAC of the encryption policy subtable in the negotiation policy, the destination MAC number of the encryption policy item is set to the number of the encryption policy subtable in the negotiation policy, the encapsulation source MAC address and the encapsulation destination MAC address of the encryption policy item are respectively set to the MAC address of the interface of the receiving end encryption bridge receiving the policy negotiation frame and the source MAC address of the policy negotiation frame, and the session key of the encryption policy item is respectively formed by the exclusive OR value of the session key component of the encryption policy subtable corresponding to the same number and the session key component of the negotiation policy; Corresponding to each encryption policy item generated by the negotiation policy, a decryption policy item is added or updated in all local decryption policy sub-tables of the receiving-end encryption bridge.

16. The method for implementing a self-organized decryption tunnel over an Ethernet link using quantum key distribution according to claim 15, wherein: Before refreshing each encryption policy sub-table in the local encryption policy table and each decryption policy sub-table in the decryption policy table based on each negotiation policy in the policy negotiation frame, the method further includes: The corresponding master key is retrieved from the second secure storage medium according to the master key ID, and the encrypted policy negotiation frame is integrity checked and decrypted to obtain the policy negotiation frame.

17. The method for implementing a self-organized decryption tunnel over an Ethernet link using quantum key distribution according to claim 15, wherein: After obtaining the session key corresponding to the encryption policy item by using the exclusive OR value of the session key component of the encryption policy subtable with the same number and the session key component of the negotiation policy, the method further includes: Enable timers and usage counts for the currently used session keys; When the timer of an encryption policy item in the encryption policy subtable times out or the usage count exceeds a threshold, the number of the session key currently used by all encryption policies in the encryption policy subtable is switched, and the key component corresponding to the switched key number is updated by collecting random numbers in real time.

18. The method for implementing a self-organized decryption tunnel over an Ethernet link using quantum key distribution according to claim 12, wherein: The method further comprises searching a local decryption policy table for a corresponding decryption policy subtable according to the source MAC address of the encrypted Ethernet frame, searching a corresponding decryption policy item based on a decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypting and decapsulating the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame, including: Searching the corresponding decryption policy sub-table from the local decryption policy table according to the source MAC address of the encrypted Ethernet frame; When the encrypted Ethernet frame is not framed, the corresponding decryption policy item is searched according to the decryption index of each decryption policy item in the corresponding decryption policy subtable, and the entire encrypted Ethernet frame is checked for ICV integrity using the keyed cryptographic hash algorithm HMAC according to the session key in the corresponding decryption policy item. After the integrity check passes, a symmetric decryption operation is performed on the original Ethernet frame to obtain the original Ethernet frame and forward it; When the encrypted Ethernet frame is a frame, the Ethernet frame with the same frame ID is searched in the frame table of the corresponding decryption strategy subtable, and the two frames are decrypted and decapsulated respectively to obtain two original frames, which are spliced ​​into a complete original Ethernet frame and then forwarded.

19. The method for implementing a self-organized decryption tunnel over an Ethernet link using quantum key distribution according to claim 12, wherein: Before receiving the policy negotiation frame sent by the first encryption bridge, the method further includes: Send a key injection request to the quantum key distribution network; The master key returned by the quantum key distribution network is obtained through the second secure storage medium integrated in the receiving-end encryption bridge, and a master key pool is established based on the master key. A key bitmap is used to identify whether each master key has been used, where each encryption bridge in the same security domain shares a master key with the same master key ID.

20. A method for implementing a self-organizing encryption and decryption tunnel in an Ethernet link using quantum key distribution, characterized in that: The second encryption bridge is a member of the first encryption bridge security domain, and the method includes: The first encryption bridge sends a policy negotiation frame to the second encryption bridge, wherein the policy negotiation frame includes a plurality of negotiation policies, and the content of each negotiation policy is a source MAC address and a session key component of a corresponding encryption policy subtable; The second encryption network bridge receives the policy negotiation frame, and based on each negotiation policy in the policy negotiation frame, refreshes each encryption policy sub-table in the encryption policy table and each decryption policy sub-table in the decryption policy table of the second encryption network bridge; The first encryption bridge searches a local encryption policy table for a corresponding encryption policy subtable according to the source MAC address of the outbound Ethernet data frame, searches the corresponding encryption policy item in the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame, encrypts and encapsulates the Ethernet data frame according to the corresponding encryption policy item, obtains an encrypted Ethernet frame, and sends it to the second encryption bridge; The second encryption bridge receives the encrypted Ethernet frame, searches for the corresponding decryption policy subtable from the local decryption policy table according to the source MAC address of the encrypted Ethernet frame, searches for the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypts and decapsulates the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame.

21. An encryption bridge, characterized in that: The encryption bridge serves as a sending end and includes: a policy negotiation frame sending module, configured to send a policy negotiation frame to the second encryption bridge, wherein the policy negotiation frame includes a plurality of negotiation policies, each negotiation policy including a source MAC address and a session key component of a corresponding encryption policy subtable, and the second encryption bridge serves as a receiving end encryption bridge; A first search module is used to search the corresponding encryption policy sub-table from the local encryption policy table for the source MAC address of the outbound Ethernet data frame; A second search module is used to search the corresponding encryption policy item from the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame; The encryption and encapsulation module is used to encrypt and encapsulate the Ethernet data frame according to the corresponding encryption policy item, obtain the encrypted Ethernet frame and send it to the second encryption bridge.

22. An encryption bridge, characterized in that: The encryption bridge serves as a receiving end and includes: A policy negotiation frame receiving module, configured to receive a policy negotiation frame sent by a first encryption bridge, wherein the first encryption bridge and the receiving end encryption bridge are in the same security domain; A policy refresh module, configured to refresh each encryption policy sub-table in its local encryption policy table and each decryption policy sub-table in its decryption policy table based on each negotiation policy in the policy negotiation frame; An encrypted Ethernet frame receiving module is used to receive the encrypted Ethernet frame sent by the first encryption bridge, where the encrypted Ethernet frame is obtained by encrypting and encapsulating the outbound Ethernet data frame by the first encryption bridge based on its local corresponding encryption policy item; The decryption and decapsulation module is used to search the corresponding decryption policy subtable from its local decryption policy table according to the source MAC address of the encrypted Ethernet frame, search the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypt and decapsulate the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame.

23. A self-organizing encryption and decryption tunnel implementation system for Ethernet links using quantum key distribution, characterized in that: The system includes a first encryption bridge, a second encryption bridge, a quantum key distribution system, and a control platform. The first encryption bridge and the second encryption bridge are connected, and the first encryption bridge and the second encryption bridge are both connected to the control platform. The first encryption bridge, the second encryption bridge, and the control platform are respectively connected to the quantum key distribution system, wherein: The management and control platform is used to provide the correspondence between the first encryption bridge, the second encryption bridge, the key agent, and the quantum network node, perform security domain division, and provide encryption bridge registration and identity binding services; The quantum key distribution system is used to provide agent functions for master key injection and online master key distribution; The first encryption bridge is configured to send a policy negotiation frame to the second encryption bridge, wherein the policy negotiation frame includes a plurality of negotiation policies, and the content of each negotiation policy is a source MAC address and a session key component of a corresponding encryption policy subtable; After receiving the policy negotiation frame, the second encryption bridge is configured to refresh each encryption policy sub-table in the local encryption policy table of the second encryption bridge and each decryption policy sub-table in the decryption policy table based on each negotiation policy in the policy negotiation frame; The first encryption bridge is configured to search a corresponding encryption policy subtable in a local encryption policy table according to the source MAC address of the outbound Ethernet data frame, search a corresponding encryption policy item in the corresponding encryption policy subtable according to the destination MAC address of the outbound Ethernet data frame, and encrypt and encapsulate the Ethernet data frame according to the corresponding encryption policy item to obtain an encrypted Ethernet frame and send it to the second encryption bridge; After the second encryption bridge receives the encrypted Ethernet frame, it is used to search the corresponding decryption policy subtable from the local decryption policy table according to the source MAC address of the encrypted Ethernet frame, search the corresponding decryption policy item based on the decryption index of each decryption policy item in the corresponding decryption policy subtable, and decrypt and decapsulate the encrypted Ethernet frame according to the corresponding decryption policy item to obtain the Ethernet data frame.

Images