WO2014047868A1

WO2014047868A1 - Protocol stack type negotiation method and device

Info

Publication number: WO2014047868A1
Application number: PCT/CN2012/082286
Authority: WO
Inventors: 何承东; 黄秋敏
Original assignee: 华为技术有限公司
Priority date: 2012-09-28
Filing date: 2012-09-28
Publication date: 2014-04-03
Also published as: CN103843449A

Abstract

A protocol stack type negotiation method and device. The method includes: sending a negotiation request message from the first negotiation device to the second negotiation device, wherein, the negotiation request message carries the protocol stack type supported by the first negotiation device, so the second negotiation device can select the protocol stack type supported by both the second negotiation device and the first negotiation device according to the protocol stack type as carried in the negotiation request message and supported by the first negotiation device; receiving the first negotiation response message responded for the negotiation request message from the second negotiation device; obtaining the protocol stack type supported by both the second and the second negotiation device according to the first negotiation response message. In the embodiments of the invention, the key management center KMC and client devices can select the same protocol stack type to setup the Key Management Interoperability Protocol KMIP sessions, and that the client devices and KMC select the protocol stack type automatically, without manual configuration and easy to maintain.

Description

Protocol stack type negotiation method and device

The present invention relates to the field of communications technologies, and in particular, to a protocol stack type negotiation method and apparatus. Background technique

Cloud computing is a business computing model that distributes computing tasks across resource pools of a large number of client devices, enabling applications to obtain computing power, storage space, and information services from client devices as needed. In cloud computing applications, data transmission is often involved. When the client device and Key Management Center (KMC, Key Manage Center) are used as data transmission partners, they can be based on Key Management Interoperability Protocol (KMIP, Key). Management Internet Protocol) The data transmission process is carried out by the session. The KMIP protocol is carried by the protocol stack. The protocol stack refers to the sum of the layers of the protocol in the file transmission process in the network. According to the relevant specifications of the KMIP protocol, there may be many types of protocol stacks carrying the KMIP protocol. Kind.

In the prior art, the client device and the KMC can respectively support one or more protocol stack types of the KMIP protocol, because the protocol stack type supported by the client device may not be exactly the same as the protocol stack type supported by the KMC, so that the client When the device performs a KMIP session with the KMC, the KMC parsing the KMIP message fails when the protocol stack type used by the client device to send the KMIP message is different from the protocol stack type used by the KMC to parse the KMIP message. Therefore, in the prior art, the manual configuration mode is adopted, and the same protocol stack type is configured on the client device and the KMC respectively, so that the type of the protocol stack used by the client device and the KMC for the KMIP session is consistent.

In the process of researching the prior art, the inventor found that, due to the large number of client devices in the cloud computing, and the possibility of dynamic increase or decrease at any time, each client device needs to be configured on both sides of the KMC. The protocol stack type is manually adjusted, so the operation is cumbersome and difficult to maintain. Summary of the invention

The embodiment of the present invention provides a protocol stack type negotiation method and device, which solves the problem that the operation is cumbersome and difficult to maintain when manually configuring the protocol stack type in the prior art.

To solve the above problem, the technical solution provided by the embodiment of the present invention is as follows:

A protocol stack type negotiation method, the method includes: the first negotiation device sends a negotiation request message to the second negotiation device, where the negotiation request message carries the protocol stack type supported by the first negotiation device, so that The second negotiation device selects a protocol stack type supported by the second negotiation device and the first negotiation device according to the protocol stack type supported by the first negotiation device that is carried in the negotiation request message; The first negotiation response message fed back by the second negotiation device according to the negotiation request message; and the protocol stack type supported by the second negotiation device and the first negotiation device is obtained according to the first negotiation response message.

A protocol stack type negotiation device, the device is disposed in a first negotiation device that performs a protocol stack type negotiation with a second negotiation device, and includes: a negotiation request message sending unit, configured to send a negotiation request message to the second negotiation device, The negotiation request message carries the protocol stack type supported by the first negotiation device, so that the second negotiation device selects the protocol stack type supported by the first negotiation device that is carried in the negotiation request message. a protocol stack type supported by the second negotiation device and the first negotiation device; the first negotiation response message receiving unit is configured to receive the negotiation request message sent by the second negotiation device according to the negotiation request message sending unit a first negotiation response message that is fed back; a protocol stack type obtaining unit, configured to obtain, according to the first negotiation response message received by the first negotiation response message receiving unit, that the second negotiation device and the first negotiation device support Protocol stack type.

A protocol stack type negotiation method, the method includes: the second negotiation device receives a negotiation request message sent by the first negotiation device, where the negotiation request message carries a protocol stack type supported by the first negotiation device; Determining, by the negotiation request message, the protocol stack type supported by the first negotiation device, selecting a protocol stack type supported by the second negotiation device and the first negotiation device; and performing the message according to the negotiation request message to the first The negotiation device feeds back the first negotiation response message, so that the first negotiation device obtains the protocol stack type supported by the second negotiation device and the first negotiation device according to the first negotiation response message.

A protocol stack type negotiation device, the device is disposed in a second negotiation device that performs a protocol stack type negotiation with the first negotiation device, and includes: a negotiation request message receiving unit, configured to receive a negotiation request message sent by the first negotiation device The negotiation request message carries the protocol stack type supported by the first negotiation device, and the protocol stack type obtaining unit is configured to perform, according to the first request carried in the negotiation request message received by the negotiation request message receiving unit Negotiating the protocol stack type supported by the device, and selecting a protocol stack type supported by the second negotiation device and the first negotiation device; the first negotiation response message sending unit is configured to perform the negotiation according to the negotiation request message receiving unit. Sending, by the requesting message, the first negotiation response message to the first negotiation device, so that the first negotiation device obtains the second negotiation device and the first negotiation device jointly supported by the first negotiation device according to the first negotiation response message. Protocol stack type.

With the protocol stack type negotiation method provided by the embodiment of the present invention, the client device does not randomly select the protocol stack type to perform the KMIP session before the KMIP session with the KMC, but one party serves as the first negotiation device, and the other party acts as the second. The device is negotiated and sent to the second negotiation device by using the first negotiation device. And the first negotiation response message fed back by the second negotiation device is received by the first negotiation device, and the protocol stack supported by the second negotiation device and the first negotiation device is obtained according to the first negotiation response message. Type, which is the type of protocol stack that is supported by the KMC and the client device. It can be seen that, in the embodiment of the present invention, the protocol stack type negotiated by the first negotiation device and the second negotiation device is a protocol stack type supported by the second negotiation device and the first negotiation device, and therefore, the KMC and the client are subsequently When the device performs a KMIP session, the protocol stack type used by the two parties is the protocol stack type supported by the KMC and the client device. Therefore, both the KMC and the client device can correctly parse the received KMIP message; and, because the client device The protocol stack type is selected through auto-negotiation with the KMC, so manual configuration is not required and maintenance is convenient. DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings to be used in the embodiments or the description of the prior art will be briefly described below. Obviously, the drawings in the following description are only It is a certain embodiment of the present invention, and other drawings can be obtained from those skilled in the art without any inventive labor.

1 is a schematic diagram of a system architecture for performing protocol stack type negotiation in an embodiment of the present invention;

2 is a schematic flowchart of a protocol stack type negotiation method in an embodiment of the present invention;

3 is a schematic flowchart of a protocol stack type negotiation method in another embodiment of the present invention;

4 is a schematic flowchart of a protocol stack type negotiation method in another embodiment of the present invention;

FIG. 5 is a schematic flowchart of a protocol stack type negotiation method according to another embodiment of the present invention; FIG.

6 is a schematic flowchart of a protocol stack type negotiation method in another embodiment of the present invention;

7 is a schematic flowchart of a protocol stack type negotiation method in another embodiment of the present invention;

8 is a schematic flowchart of a protocol stack type negotiation method in another embodiment of the present invention;

9 is a schematic flowchart of a protocol stack type negotiation method according to another embodiment of the present invention;

FIG. 10 is a schematic flowchart of a protocol stack type negotiation method according to another embodiment of the present invention; FIG.

11 is a schematic flowchart of a protocol stack type negotiation method according to another embodiment of the present invention;

FIG. 12 is a schematic structural diagram of a protocol stack type negotiation apparatus according to an embodiment of the present invention; FIG.

13 is a schematic structural diagram of a protocol stack type negotiation apparatus in another embodiment of the present invention;

FIG. 14 is a schematic structural diagram of a protocol stack type negotiation apparatus according to another embodiment of the present invention;

15 is a schematic structural diagram of a protocol stack type negotiation apparatus in another embodiment of the present invention;

16 is a schematic structural diagram of a protocol stack type negotiation apparatus in another embodiment of the present invention;

17 is a schematic structural diagram of a protocol stack type negotiation apparatus in another embodiment of the present invention; 18 is a schematic structural diagram of a protocol stack type negotiation apparatus according to another embodiment of the present invention. FIG. 19 is a schematic structural diagram of a protocol stack type negotiation apparatus according to another embodiment of the present invention.

20 is a schematic structural diagram of a protocol stack type negotiation apparatus in another embodiment of the present invention;

FIG. 21 is a schematic structural diagram of a protocol stack type negotiation apparatus according to another embodiment of the present invention. The present invention will be further described in detail with reference to the accompanying drawings, in which FIG. An embodiment. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

As shown in FIG. 1 , it is a schematic diagram of a system architecture for protocol stack type negotiation in an embodiment of the present invention. The system includes multiple client devices and a KMC, where each client device performs a KMIP session with the KMC. In the embodiment of the present invention, the protocol stack type negotiation may be initiated by the client device, or the protocol stack type negotiation may be initiated by the KMC. The protocol stack type negotiation is performed with the KMC, and then the negotiated protocol stack type is used to perform the KMIP session with the KMC. For the convenience of description, in the client device and the KMC that negotiate the protocol stack type, the party that defines the protocol stack type negotiation is the first negotiation device, and the other party is the second negotiation device. As shown in FIG. 2, it is an embodiment of a protocol stack type negotiation method according to the present invention. The embodiment describes the negotiation process from the first negotiation device side:

Step 201: The first negotiation device sends a negotiation request message to the second negotiation device, where the negotiation request message carries the protocol stack type supported by the first negotiation device, so that the second negotiation device sends the first negotiation device according to the negotiation request message. The supported protocol stack type selects the protocol stack type supported by the second negotiation device and the first negotiation device.

When the first negotiation device is a client device, the second negotiation device is a KMC; when the first negotiation device is a KMC, the second negotiation device is a client device.

The negotiation request message may carry all the protocol stack types supported by the first negotiation device, and may also carry a partial protocol stack type supported by the first negotiation device.

The negotiation request message may further carry the protocol stack type priority set by the first negotiation device, so that the second negotiation device can use the protocol stack type supported by the first negotiation device carried in the negotiation request message, and the first negotiation. The protocol stack type priority set by the device is selected, and a protocol stack type supported by the second negotiation device and the first negotiation device is selected. In the embodiment of the present invention, the protocol stack type used by the first negotiation device and the second negotiation device to perform the KMIP session may be various, for example, each protocol stack type shown in Table 1.

Table

As can be seen from Table 1, when the protocol stack type used for the KMIP session is type one, the protocol stack includes

KMIP, Transport Layer Security (TLS) protocol and Transmission Control Protocol (TCP); when the protocol stack type used for KMIP sessions is type 2, the protocol stack contains KMIP and hypertext. Under the transport protocol, the Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) protocol and the TCP protocol are added. When the protocol stack type used for the KMIP session is type 3, the protocol stack includes the KMIP and the hypertext transfer protocol. HTTP, Hypertext Transfer Protocol) TLS protocol and TCP four protocols; when the protocol stack type used for KMIP session is type four, the protocol stack includes KMIP, Simple Object Access Protocol (SOAP), HTTPS protocol and TCP. Four protocols; when the protocol stack type used for the KMIP session is type five, the protocol stack includes five protocols: KMIP, S0AP, HTTP, TLS, and TCP; when the protocol stack type used for the KMIP session is type six , the protocol stack contains KMIP, TCP and Internet Protocol Security (IPSec, Internet Protocol Security) protocol three protocols.

Step 202: The first negotiation device receives a first negotiation response message that is sent by the second negotiation device according to the negotiation request message.

The first negotiation response message carries the protocol stack type supported by the second negotiation device, and the protocol stack type carried in the first negotiation response message may include: the first negotiation device carries the first message according to the received negotiation request message. Negotiating the protocol stack type supported by the device, determining the at least one protocol stack type supported by the second negotiation device and the first negotiation device; or the protocol stack type supported by the second negotiation device.

In the embodiment of the present invention, when the protocol stack type supported by the second negotiation device and the first negotiation device is at least two protocol stack types, the first negotiation response message may carry the second negotiation device from the second negotiation device. A protocol stack type selected from the types of protocol stacks supported by the first negotiation device. When the negotiation request message sent by the first negotiation device carries the protocol stack type priority set by the first negotiation device, the first negotiation response message may carry a protocol stack type supported by the two parties selected by the second negotiation device, where A protocol stack type supported by the two parties is a second negotiation device selected by the second negotiation device according to the protocol stack type supported by the first negotiation device and the protocol stack type priority set by the first negotiation device. The type of protocol stack that is supported by the first negotiation device.

In the embodiment of the present invention, the first negotiation response message may carry the protocol stack type supported by the second negotiation device, and further may carry the protocol stack type priority preset by the second negotiation device, so that the first negotiation device can Selecting a second type according to the protocol stack type priority supported by the second negotiation device carried in the first negotiation response message, from the at least one protocol stack type supported by the second negotiation device that is carried by the second negotiation device The type of protocol stack supported by the negotiation device and the first negotiation device.

In addition, the entity that pre-sets the priority of the protocol stack type may be the two sides of the protocol stack type negotiation, or may be only one of the following, and may specifically include the following three situations: The first negotiation device presets the protocol stack type priority; The second negotiation device presets the protocol stack type priority; the first negotiation device and the second negotiation device both preset the protocol stack type priority.

For the first negotiation device and the second negotiation device, the protocol stack type priority is set in advance. In order to enable the two parties to select the protocol stack type according to the same protocol stack type priority, both the first negotiation device and the second negotiation device may be adopted. The first negotiation device is pre-agreed when the priority of the same protocol stack type is set in advance, or when the priority of the protocol stack type set by the first negotiation device is different from the priority of the protocol stack type preset by the second negotiation device. Pre-set protocol stack type priority, or pre-agreed the protocol stack type priority preset by the second negotiation device.

Step 203: Obtain a protocol stack type supported by the second negotiation device and the first negotiation device according to the first negotiation response message.

If the first negotiation response message carries at least one protocol stack type supported by the two parties determined by the second negotiation device, the first negotiation device may select one of the at least one protocol stack type carried in the first negotiation response message. The protocol stack type supported by the second negotiation device and the first negotiation device.

If the first negotiation response message carries the protocol stack type supported by the second negotiation device, the first negotiation device may select the second protocol stack type supported by the second negotiation device that is carried in the received first negotiation response message, and select the second The type of protocol stack supported by the negotiation device and the first negotiation device.

The protocol stack type supported by the second negotiation device and the first negotiation device may be one or more. The number of protocol stacks supported by the second negotiation device and the first negotiation device may be multiple. The processing flow may also be included in the following: a protocol stack supported by the second negotiation device and the first negotiation device When the type is greater than one, the first negotiation device first selects a protocol stack type from the protocol stack type supported by the second negotiation device and the first negotiation device, and then sends a second negotiation response message to the second negotiation device, and the second negotiation is performed. The response message carries a protocol stack type supported by both parties finally selected by the first negotiation device.

The protocol stack type is selected from the protocol stack type supported by the second negotiation device and the first negotiation device: at least one supported by the second negotiation device and the first negotiation device. In the protocol stack type, a protocol stack type is randomly selected. From at least one protocol stack type supported by the second negotiation device and the first negotiation device, a protocol stack type is selected according to a protocol stack type priority preset by the first negotiation device. The at least one protocol stack type supported by the second negotiation device and the first negotiation device is selected according to a protocol stack type priority preset by the second negotiation device carried in the first negotiation response message.

In the embodiment of the present invention, in order to prevent man-in-the-middle attacks, the entire protocol stack negotiation process may be encrypted, for example, using public-private key mechanism encryption and decryption (ie, asymmetric key encryption and decryption), or using symmetric key encryption and decryption, of course. Other encryption and decryption processing methods may also be used, which are not limited in this embodiment of the present invention.

When the first negotiation device sends the negotiation request message to the second negotiation device, the key information is exchanged with the second negotiation device, so that the first negotiation device and the second negotiation device are configured according to the public information. The above-mentioned key information uses the public-private key encryption and decryption mechanism to negotiate the protocol stack type, which may include the following two situations:

Determining, by the first negotiation device, the first negotiation device private key and the first negotiation device public key, and storing the first negotiation device private key, and sending the first negotiation device public key to the second negotiation device, where the first negotiation device is private The key is used to encrypt the message sent to the second negotiation device (for example, the negotiation request message and the second negotiation response message), and the message received from the second negotiation device (for example, according to the first negotiation device public key encryption) The first first negotiation response message is decrypted, and the first negotiation device public key is used by the second negotiation device for the message received from the first negotiation device (for example, the negotiation request message encrypted according to the first negotiation device private key) Decrypting with the second negotiation response message, and encrypting the message (for example, the first negotiation response message) sent to the first negotiation device;

The second negotiation device private key and the second negotiation device public key are preset by the second negotiation device, and the second negotiation device obtains the second preset before the first negotiation device sends the negotiation request message to the second negotiation device. Negotiating the device public key, encrypting the message sent to the second negotiation device (for example, the negotiation request message and the second negotiation response message) by using the second negotiation device public key, and using the second negotiation device public key pair to negotiate from the second The message received by the device (for example, the first negotiation response message encrypted according to the second negotiation device private key) is decrypted. Correspondingly, the second negotiation device uses the second negotiation device private key pair to send the message to the first negotiation device. (example For example, the first negotiation response message is encrypted, and the message received from the first negotiation device is obtained by using the second negotiation device private key (for example, the negotiation request message and the second negotiation response encrypted according to the second negotiation device public key) Message) Decrypt.

When symmetric key encryption and decryption is employed, the symmetric key is shared with the second negotiation device before the first negotiation device sends the negotiation request message to the second negotiation device. On one hand, before the first negotiation device sends the message to the second negotiation device, the first negotiation device encrypts the message sent to the second negotiation device according to the symmetric key and the obtained random number, obtains the message ciphertext, and simultaneously sends the message when the message is sent. The message ciphertext is used to enable the second negotiation device to decrypt the received message ciphertext to obtain the message plaintext, compare the message plaintext with the received message, and continue the protocol stack type negotiation when the comparison result is the same; After receiving the message ciphertext sent by the second negotiation device at the same time as the message is sent, the first negotiation device decrypts the message ciphertext according to the symmetric key, obtains the message plaintext, and compares the message plaintext with the received message. When the comparison result is the same, the protocol stack type negotiation is continued. The message ciphertext is a message ciphertext obtained by the second negotiation device encrypting the message sent to the first negotiation device according to the symmetric key and the obtained random number.

According to the foregoing process, in the embodiment of the present invention, the protocol stack type negotiated by the first negotiation device and the second negotiation device is a protocol stack type supported by the two parties. Therefore, when the KMC and the client device perform a KMIP session, The protocol stack type adopted by the two parties is the protocol stack type supported by the KMC and the client device. Therefore, both the KMC and the client device can correctly parse the received KMIP message; and, because the client device and the KMC pass the automatic Negotiation, select the protocol stack type, so no manual configuration is required, which is easy to maintain. As shown in FIG. 3, it is another embodiment of the protocol stack type negotiation method of the present invention. The embodiment describes the negotiation process from the second negotiation device side:

Step 301: The second negotiation device receives the negotiation request message sent by the first negotiation device, where the negotiation request message carries the protocol stack type supported by the first negotiation device.

The negotiation request message may carry all the protocol stack types supported by the first negotiation device, and may also carry a partial protocol stack type supported by the first negotiation device. The negotiation request message may further carry the first negotiation device preset. Protocol stack type priority.

When the second negotiation device is a KMC, the first negotiation device is a client device; when the second negotiation device is a client device, the first negotiation device is a KMC.

Step 302: The second negotiation device selects a protocol stack type supported by the second negotiation device and the first negotiation device according to the protocol stack type supported by the first negotiation device that is carried in the negotiation request message. For example, the protocol stack type supported by the first negotiation device carried in the negotiation request message is type one, type two, and type three, and all protocol stack types supported by the second negotiation device are type one, type two, and type five. The protocol stack types supported by the second negotiation device and the first negotiation device selected by the second negotiation device are type one and type two.

In the embodiment of the present invention, when the protocol stack type supported by the second negotiation device and the first negotiation device is at least two protocol stack types, the second negotiation device selects the second negotiation device and the first negotiation device to support the same. After the protocol stack type, at least one protocol stack type supported by the two parties may be determined; or, one protocol stack type is selected from the protocol stack types supported by the second negotiation device and the first negotiation device.

The second negotiation device may select a protocol stack type by using any one of the following methods: a protocol stack type is randomly selected from the protocol stack types supported by the second negotiation device and the first negotiation device; and the second negotiation device and the first The protocol stack type supported by the negotiation device is selected according to the protocol stack type priority set by the first negotiation device carried in the negotiation request message; and the protocol stack type priority set according to the second negotiation device is selected. Protocol stack type.

In addition, when the negotiation request message carries both the protocol stack type supported by the first negotiation device and the protocol stack type priority set by the first negotiation device, the protocol stack supported by the first negotiation device carried in the negotiation request message may be used. The type and the priority of the protocol stack type preset by the first negotiation device are selected, and a protocol stack type supported by the second negotiation device and the first negotiation device is selected.

Step 303: The second negotiation device feeds back the first negotiation response message to the first negotiation device according to the negotiation request message, so that the first negotiation device obtains the protocol supported by the second negotiation device and the first negotiation device according to the first negotiation response message. Stack type.

The type of the protocol stack carried in the first negotiation response message may include: a protocol stack type supported by the second negotiation device selected by the second negotiation device and the first negotiation device in step 302, so that the first negotiation device can receive the After the first negotiation response message, the protocol stack type supported by the second negotiation device and the first negotiation device can be directly obtained from the first negotiation response message; or at least one protocol stack type supported by the two parties, so that the first negotiation is performed. The device may select a protocol stack type supported by the second negotiation device and the first negotiation device from the at least one protocol stack type supported by the two parties in the first negotiation response message; or the second negotiation device negotiates from the second negotiation device. A protocol stack type supported by the two parties selected by the device and the protocol stack type supported by the first negotiation device, so that the first negotiation device can directly obtain the second negotiation device and the first negotiation response message from the received first negotiation response message. a protocol stack type supported by a negotiation device; or, a second negotiation setting Protocol stack supported type, so that the first device may negotiate receiving the first negotiation response message, support device capable of responding to a second negotiation message carried in the first negotiation protocol stack type, select the second negotiation device a type of protocol stack supported by the first negotiation device, and subsequently performed by the first negotiation device and the second negotiation device

In the KMIP session, the KMIP session is performed by using the protocol stack type supported by the second negotiation device and the first negotiation device.

In the embodiment of the present invention, when the first negotiation response message carries at least one protocol stack type supported by the two parties, the first negotiation response message may further carry a protocol stack type priority preset by the second negotiation device, so that The first negotiating device selects a second negotiating device from the at least one protocol stack type jointly supported by the second negotiation device that is carried by the second negotiation device that is carried by the second negotiation device according to the protocol stack type priority set by the second negotiation device. The protocol stack type supported by the first negotiation device.

If the protocol stack type carried in the first negotiation response message is the protocol stack type supported by the second negotiation device, step 302 may be performed first, and then step 303 is performed; or step 303 may be performed first, and then step 302 is performed; Steps 302 and 303 are performed, and the embodiment of the present invention is not limited.

The first negotiation response message may carry the protocol stack type supported by the second negotiation device, and further may carry the protocol stack type priority preset by the second negotiation device, so that the first negotiation device can be configured according to the first negotiation response message. The protocol stack type supported by the second negotiation device carried in the second negotiation device and the protocol stack type priority preset by the second negotiation device determine a protocol stack type supported by the second negotiation device and the first negotiation device.

In addition, in the embodiment of the present invention, the following optional steps may be further included: the second negotiation device receives the second negotiation response message sent by the first negotiation device, where the second negotiation response message carries the two parties selected by the first negotiation device. A type of protocol stack that is commonly supported. The first negotiation device may select a protocol stack type selected from the protocol stack types supported by the second negotiation device and the first negotiation device according to the received first negotiation response message, and subsequently negotiate with the first negotiation device. When the device performs a KMIP session, the KMIP session is performed using one of the protocol stack types selected above.

When the second negotiation device receives the negotiation request message sent by the first negotiation device, the key information is exchanged with the first negotiation device to enable the first negotiation device and the second negotiation device. The protocol stack type negotiation is performed by using a public-private key encryption and decryption mechanism according to the key information, which may include the following two situations:

The second negotiation device private key and the second negotiation device public key are preset by the second negotiation device, and the second negotiation device private key is stored, and the second negotiation device public key is sent to the first negotiation device, and the second negotiation device is private. Key use Encrypting a message (eg, a first negotiation response message) sent to the first negotiation device, and receiving a message received from the first negotiation device (eg, a negotiation request message encrypted according to the second negotiation device public key) The second negotiation device message is decrypted, and the second negotiation device public key is used by the first negotiation device to receive the message from the second negotiation device (for example, the first negotiation response message encrypted according to the second negotiation device private key) Decrypting, and encrypting messages sent to the second negotiating device (eg, the negotiation request message and the second negotiation response message);

The first negotiation device private key and the first negotiation device public key are preset by the first negotiation device. Before the second negotiation device receives the negotiation request message sent by the first negotiation device, the first negotiation device obtains the preset Negotiating the device public key, encrypting the message (for example, the first negotiation response message) sent to the first negotiation device by using the first negotiation device public key, and receiving the first negotiation device from the first negotiation device by using the first negotiation device public key pair The message is decrypted according to the first negotiation device private key encrypted negotiation request message and the second negotiation response message, and the first negotiation device uses the first negotiation device private key pair to send to the second negotiation device. The message (eg, the negotiation request message and the second negotiation response message) is encrypted, and the message received from the second negotiation device is obtained using the first negotiation device private key (eg, the first encrypted according to the first negotiation device public key) Negotiate response message) Decrypt.

When symmetric key encryption and decryption is used, the symmetric key is shared with the first negotiation device before the second negotiation device receives the negotiation request message sent by the first negotiation device. On the one hand, the second negotiation device receives the message ciphertext sent by the first negotiation device at the same time as the message is sent, decrypts the message ciphertext according to the symmetric key, obtains the message plaintext, and compares the message plaintext with the received message. When the comparison result is the same, the protocol stack type negotiation is continued, where the message ciphertext is that the first negotiation device encrypts the message sent to the first negotiation device according to the symmetric key and the obtained random number, and the obtained message is dense. On the other hand, before sending the message to the first negotiation device, the second negotiation device encrypts the message sent to the first negotiation device according to the symmetric key and the obtained random number, obtains the message ciphertext, and sends the message. The message ciphertext is sent at the same time, so that the first negotiation device decrypts the received message ciphertext to obtain the message plaintext, compares the message plaintext with the received message, and when the comparison result is the same, continues the protocol stack type negotiation.

According to the foregoing process, in the embodiment of the present invention, the protocol stack type negotiated by the first negotiation device and the second negotiation device is a protocol stack type supported by the two parties. Therefore, when the KMC and the client device perform a KMIP session, The protocol stack type adopted by the two parties is the protocol stack type supported by the KMC and the client device. Therefore, both the KMC and the client device can correctly parse the received KMIP message; and, because the client device and the KMC pass the automatic Negotiation, select the protocol stack type, so no manual configuration is required, which is easy to maintain. As shown in FIG. 4, another embodiment of the method for negotiating the protocol stack type of the present invention is as follows: in this embodiment, the first negotiation device is a client device, and the second negotiation device is a KMC, where the KMC unilaterally selects a protocol stack type, and then The selected protocol stack type is sent to the client device, and the information transmitted by the protocol stack type is encrypted and decrypted by using the public and private keys set by the KMC. The specific processing flow is as follows:

Step 401: The client device encrypts the negotiation request message to be sent by using the KMC public key.

The KMC can pre-set the KMC public key and the KMC private key, publish the KMC public key, and save the KMC private key.

In the embodiment of the present invention, the negotiation request message may carry only all the protocol stack types supported by the client device (for example, type one, type two, and type three), and may further carry each type of cooperation set by the client device. The corresponding priority, for example, the priority corresponding to each protocol stack type is shown in Table 2.

The subsequent KMC can select the protocol stack type supported by the KMC and the client device from all the protocol stack types supported by the KMC according to all protocol stack types supported by the client device carried in the received negotiation request message. The number of protocol stacks supported by the KMC and the client device may be multiple. If the negotiation request message carries the priority corresponding to each protocol stack type set by the client device, the KMC may be based on a preset priority policy. Select a protocol stack type from the protocol stack type supported by the KMC and the client device.

Step 402: The client device sends the negotiation request message encrypted in step 401 to the KMC.

Step 403: The KMC decrypts the received encrypted negotiation request message by using the KMC private key. Step 404: The KMC determines, according to all protocol stack types supported by the client device carried in the negotiation request message, all the protocol stack types supported by the KMC and the client device according to all protocol stack types supported by the KMC.

Step 405: The KMC selects a protocol stack type from all the protocol stack types supported by the determined KMC and the client device.

The KMC may select a protocol stack type in any of the following ways: From the protocol stack types supported by the KMC and the client device, randomly select a protocol stack type; Set the protocol stack type priority. From all the protocol stack types supported by the KMC and the client device, select a protocol stack type according to a preset policy. For example, preset a protocol stack with the highest priority. Type, or pre-set to select a protocol stack type with the lowest priority; according to the protocol stack type priority preset by the client device carried in the received negotiation request message, all supported by the KMC and the client device In the protocol stack type, a protocol stack type is selected according to a preset policy, for example, a protocol stack type with the highest priority is selected in advance, or a protocol stack type with the lowest priority is selected in advance.

In the embodiment of the present invention, when both the KMC and the client device have the protocol stack type priority set in advance, the same protocol stack type priority may be preset in advance, or the protocol stack type priority and the client preset by the KMC are used. When the priority of the protocol stack type preset by the device is different, the priority of the protocol stack type preset by the KMC may be pre-agreed, or the protocol stack type priority preset by the client device may be pre-agreed.

Step 406: The KMC encrypts the first negotiation response message to be sent by using the KMC private key, and the first negotiation response message carries a protocol stack type selected in step 405.

Step 407: The KMC sends the encrypted first negotiation response message to the client device.

Step 408: The client device decrypts the received encrypted first negotiation response message by using the KMC public key.

The client device may directly obtain a protocol stack type supported by the KMC and the KMC supported by the KMC from the first negotiation response message, and the subsequent client device may use the protocol stack type to perform a KMIP session with the KMC.

In addition, when the information transmitted by the protocol stack type is encrypted and decrypted by using the public-private key mechanism, the main body of the public-private key pair may also be a client device, wherein the client device may pre-set the client public key and the client. End the private key, and publish the client public key, and save the client private key. The subsequent client device may encrypt the message to be sent to the KMC by using the client private key, and decrypt the message received from the KMC by using the client private key, and accordingly, the KMC utilizes the The client public key decrypts the message received from the client device and encrypts the message to be sent to the client device using the client public key. Specifically, the client device encrypts the negotiation request message sent to the KMC by using the client private key, and the KMC decrypts the received encrypted negotiation request message by using the client public key; when the KMC returns the first to the client device When the response message is negotiated, the first negotiation response message to be sent by the client public key is encrypted, and the client device decrypts the received encrypted first negotiation response message by using the client private key. As shown in FIG. 5, the protocol stack type negotiation method of the present invention is another embodiment. In this embodiment, the first negotiation device is a client device, and the second negotiation device is a KMC, where the KMC and the client device jointly select a protocol. The stack type uses the public-private key set by the client device to encrypt and decrypt the information transmitted during the negotiation of the protocol stack type. The specific processing flow is as follows:

Step 501: The client device encrypts the negotiation request message to be sent by using the client private key, and the negotiation request message carries all protocol stack types supported by the client device.

The client device may preset the client public key and the client private key, advertise the client public key, and save the client private key.

Step 502: The client device sends the negotiation request message encrypted in step 501 to the KMC.

Step 503: The KMC decrypts the received encrypted negotiation request message by using the client public key. The system may have multiple client devices respectively performing KMIP sessions with the KMC, and each client device may separately set the client public key and the client private key, and advertise the client public key, and save the client private key, KMC. After receiving the client public key advertised by the client device, the client public key may be stored in association with the identifier of the client device, so as to receive the negotiation request message sent by the client device, and then carry the message according to the negotiation request message. The identifier of the client device, in the corresponding relationship between the pre-stored client public key and the identifier of the client device, find the client public key corresponding to the identifier of the client device, and negotiate with the found client public key pair The request message is decrypted, and the correspondence between the client public key stored in the KMC and the identifier of the client device is shown in Table 3.

Step 504: The KMC selects all protocol stack types supported by the KMC and the client device according to all protocol stack types supported by the client device carried by the negotiation request message and all protocol stack types supported by the KMC.

Step 505: The KMC encrypts the first negotiation response message to be sent by using the client public key. The first negotiation response message carries all protocol stack types supported by the KMC and the client device.

In the embodiment of the present invention, the first negotiation response message may only carry all the protocol stack types supported by the KMC and the client device, and may further carry the priority corresponding to each protocol stack type set by the KMC. In addition, the first negotiation response message may also carry only all protocol stack types supported by the KMC, and may be combined by the client device according to all protocol stack types supported by the KMC carried by the first negotiation response message, and the client device itself. All the types of protocol stacks supported by the KMC and the client device are selected. The first negotiation response message may further carry the priority corresponding to each protocol stack type set by the KMC.

Step 506: The KMC sends the encrypted first negotiation response message to the client device.

Step 507: The client device decrypts the received encrypted first negotiation response message by using the client private key.

The protocol stack supported by the KMC and the client device can be one or more. When the KMC and the client device support more than one protocol stack, the client device can also support the KMC and the client device. In all protocol stack types, a protocol stack type is pre-selected, and the selected protocol stack type is sent to the KMC, so that when the client device performs a KMIP session with the KMC, both parties use the selected protocol stack type. The KMIP session, therefore, the embodiment of the present invention may further include multiple optional steps, as follows, step 508 to step 511.

Step 508: The client device selects a protocol stack type from all protocol stack types supported by the KMC and the client device carried by the first negotiation response message.

The client device may adopt any one of the following methods when selecting a protocol stack type: randomly select a protocol stack type from all protocol stack types supported by the _KMC and the client device;

Among all the protocol stack types supported by the KMC and the client device, a protocol stack type is selected according to the protocol stack type priority set by the client device; from all protocol stack types supported by the KMC and the client device, according to the first The priority of the protocol stack type preset by the KMC carried in the negotiation response message is selected as a protocol stack type.

Step 509: The client device encrypts the second negotiation response message to be sent by using the client private key, and the second negotiation response message carries a protocol stack type selected in step 508.

Step 510: The client device sends the encrypted second negotiation response message to the KMC.

Step 511: The KMC decrypts the encrypted second negotiation response message by using the client public key, and the KMC uses the protocol stack type carried in the second negotiation response message when the KMC performs a KMIP session with the client device. The client device performs a KMIP session.

In addition, when the public-private key mechanism is used to encrypt and decrypt the information transmitted during the negotiation of the protocol stack type, the main body of the public-private key pair may also be a KMC. The specific encryption and decryption processing process is not described here. As shown in FIG. 6 , another embodiment of the method for negotiating a protocol stack type according to the present invention is as follows: in this embodiment, the first negotiation device is a client device, and the second negotiation device is a KMC, where the KMC unilaterally selects a protocol stack type, and then The selected protocol stack type is sent to the client device, and the information transmitted by the protocol stack type is encrypted and decrypted by using the symmetric key, and the robustness of the random number enhanced encryption and decryption is introduced to ensure the protocol stack type negotiation process information. It has not been tampered with, and its specific processing flow is as follows:

Step 601: The client device and the KMC share a symmetric key Key.

Step 602: The client device sends a negotiation request message to the KMC.

In the embodiment of the present invention, the negotiation request message carries two parts of content: Contentl, Content2.

Contentl may contain only all protocol stack types supported by the client device itself, and may further include the priority corresponding to each protocol stack type set by the client device.

Content2 is the ciphertext output obtained after executing the encryption function encryptFunc (ClientRandl, Contentl, Key). The parameter ClientRandl is a random number generated by the client device. It is the same as the parameter Contentl as the plaintext input in the encryption algorithm. The parameter Key is the symmetric key Key in step 601, and is used as the encryption key in the function encryptFunc.

Step 603: The KMC determines the validity of the negotiation request message.

The KMC first performs a decryption function decryptFunc (Content2, Key carried in step 602) to obtain a plaintext output. The parameter Key is the symmetric key Key in step 601, and is used as the decryption key in the function decryptFunc. If the decryption fails, indicating that the negotiation request message is invalid (may have been tampered with), the negotiation is terminated. If the decryption is successful, get ClientRandl ' , Contentl '. The KMC then compares Contentl ' with the Contentl carried in step 602. If the two are inconsistent, indicating that the negotiation request message is invalid (may have been tampered with), the negotiation is terminated. If the two are consistent, indicating that the negotiation request message is valid, continue to negotiate.

Step 604: The KMC determines, according to all protocol stack types supported by the client device in the Content1 carried in the negotiation request message, and all protocol stack types supported by the KMC, to determine all protocol stack types supported by the KMC and the client device.

Step 605: The KMC selects a protocol stack type from all the protocol stack types supported by the determined KMC and the client device.

The KMC can select a protocol stack type in any of the following ways: From the protocol stack types supported by the KMC and the client device, a protocol stack type is randomly selected; according to the client device carried in the negotiation request message. The protocol stack type priority is set. From all the protocol stack types supported by the KMC and the client device, a protocol stack type is selected according to a preset policy, for example, a protocol stack type with the highest priority is selected in advance. Or pre-set to select a protocol stack type with the lowest priority; From all protocol stack types supported by the KMC and the client device, according to the protocol stack type priority preset by the KMC, a protocol stack type is selected according to a preset policy, for example, a protocol with the highest priority is selected in advance. Stack type, or pre-set to select a protocol stack type with the lowest priority.

Step 606: The KMC sends a first negotiation response message to the client device, where the first negotiation response message carries two parts of content: Content3 and Content4.

Content3 is a protocol stack type selected in step 605.

Content4 is the ciphertext output obtained by executing the encryption function encryptFunc (random number combination, Content3, Key). The parameter "random number combination" may only include the ClientRandl ' decrypted in step 603, and may further include the random number KMCRand1 generated by the KMC. Two random numbers can be combined by means of / or / connection. The "random number combination" is the same as the plaintext input in the encryption algorithm, and the parameter Key is the symmetric key Key in step 601, and is used as the encryption key in the function encryptFunc.

Step 607: The client device determines validity of the first negotiation response message.

The client device first performs a decryption function decryptFunc (Contents Key carried in step 606) to obtain a plaintext output. If the decryption fails, indicating that the first negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the decryption is successful, get the random number combination ', Cont _en t3 '. The client device compares Contents ' with Content3 carried in step 606. If the two are inconsistent, indicating that the first negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the two are consistent, indicating that the first negotiation response message is valid, the protocol stack type in Cont _en t3 is selected as the negotiated protocol stack type. As shown in FIG. 7 , another embodiment of the method for negotiating a protocol stack of the present invention is as follows: in this embodiment, the first negotiation device is a client device, and the second negotiation device is a KMC, where the KMC and the client device jointly select a protocol. The stack type, the client device sends the finally selected protocol stack type to the KMC, and uses the symmetric key to encrypt and decrypt the information transmitted during the negotiation of the protocol stack type, and introduces random number enhancement encryption and decryption robustness. To ensure that the protocol stack negotiation process information has not been tampered with, the specific processing procedure is as follows: Step 701: The client device and the KMC share the symmetric key Key.

Step 702: The client device sends a negotiation request message to the KMC.

Content2 is the ciphertext output obtained after executing the encryption function encryptFunc (ClientRandl, Contentl, Key). The parameter ClientRandl is a random number generated by the client device, which is the same as the parameter Contentl. For the plaintext input in the encryption algorithm, the parameter Key is the symmetric key Key in step 701, and is used as the encryption key in the function encryptFunc.

Step 703: The KMC determines the validity of the negotiation request message.

The KMC first performs the decryption function decryptFunc (Content2, Key carried in step 702) to obtain the plaintext output. The parameter Key is the symmetric key Key in step 701, and is used as the decryption key in the function decryptFunc. If the decryption fails, indicating that the negotiation request message is invalid (may have been tampered with), the negotiation is terminated. If the decryption is successful, get ClientRandl ' , Content 1 '. The KMC then compares the Content with the Contentl carried in step 702. If the two are inconsistent, indicating that the negotiation request message is invalid (may have been tampered with), the negotiation is terminated. If the two are consistent, indicating that the negotiation request message is valid, continue to negotiate.

Step 704: The KMC selects all protocol stack types supported by the KMC and the client device according to all protocol stack types supported by the client device in the Content1 carried in the negotiation request message, and all protocol stack types supported by the KMC.

Step 705: The KMC sends the first negotiation response message to the client device.

In the embodiment of the present invention, the first negotiation response message carries two parts of content: Content3, Content4. Content3 can contain only all the protocol stack types supported by the KMC and the client device, and can further include the priority corresponding to each protocol stack type set by the KMC.

Content4 is the ciphertext output obtained after executing the encryption function encryptFunc (random number combination, Content3, Key). The parameter "random number combination" may include only the ClientRand1 ' obtained by decrypting in step 703, and may further include the random number KMCRand1 generated by the KMC. Two random numbers can be combined by means of / or / connection. The "random number combination" is the same as the plaintext input in the encryption algorithm, and the parameter Key is the symmetric key Key in step 701, and is used as the encryption key in the function encryptFunc. In addition, the Cont _en t3 in the first negotiation response message may also include only all protocol stack types supported by the KMC, and may be combined with the client device according to all protocol stack types supported by the KMC carried by the first negotiation response message. The protocol stack type supported by the device itself is selected by the KMC and the client device. The Cont _en t3 in the first negotiation response message may further carry the priority corresponding to each protocol stack type set by the KMC.

The protocol stack supported by the KMC and the client device can be one or more. When the KMC and the client device support more than one protocol stack, the client device can also support the KMC and the client device. In all protocol stack types, a protocol stack type is pre-selected, and the selected protocol stack type is sent to the KMC, so that when the client device performs a KMIP session with the KMC, both parties use the selected protocol stack type. KMIP session, therefore, the embodiment of the present invention further includes multiple optional Steps, as follows, step 707, step 708 and step 709.

Step 706: The client device determines validity of the first negotiation response message.

The client device first performs a decryption function decryptFunc (Contents Key carried in step 705) to obtain a plaintext output. If the decryption fails, indicating that the first negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the decryption is successful, get the random number combination ', Cont _en t3 '. The client device compares Contents ' with Content3 carried in step 705. If the two are inconsistent, indicating that the first negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the two are consistent, the first negotiation response message is valid, and the negotiation is continued. Step 707: The client device selects a protocol stack type from all protocol stack types supported by the KMC and the client device in the Cont _en t3 carried in the first negotiation response message.

Wherein, when the client device selects the protocol stack type, any one of the following selection methods may be adopted:

_Among all the protocol stack types supported by the _KMC and the client device, a protocol stack type is randomly selected;

Among all the protocol stack types supported by the KMC and the client device, according to the protocol stack type priority preset by the client device, a protocol stack type is selected according to a preset policy, for example, a preset with the highest priority is selected. The protocol stack type, or a protocol stack type with the lowest priority is selected in advance; from all the protocol stack types supported by the KMC and the client device, the protocol stack type preset according to the KMC carried in the first negotiation response message takes precedence. Level, select a protocol stack type according to a preset policy, for example, pre-set to select a protocol stack type with the highest priority, or pre-set to select a protocol stack type with the lowest priority.

Step 708: The client device sends a second negotiation response message to the KMC, where the second negotiation response message carries two parts: Content5, Content6.

Content5 is a protocol stack type selected in step 707.

Content6 is the ciphertext output obtained by executing the encryption function encryptFunc (random number combination, Content5, Key). The parameter "random number combination" may include only the ClientRand1 in the negotiation request message, or only the random number ClientRand2 regenerated by the client device, and may further include the random number KMCRand1 generated by the KMC in Content4 in step 705. Two random numbers can be combined by means of / or / connection. The "random number combination" is the same as the plaintext input in the encryption algorithm, and the parameter Key is the symmetric key Key in step 701, and is used as the encryption key in the function encryptFunc.

Step 709: The KMC determines the validity of the second negotiation response message.

The KMC first executes the decryption function decryptFunc (Content6, Key carried in step 708) to obtain the plaintext output. If the decryption fails, indicating that the second negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the decryption is successful, get the random number combination ', Content5'. KMC compares Content5 ' With Content5 carried in step 708, if the two are inconsistent, indicating that the second negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the two are consistent, indicating that the second negotiation response message is valid, the protocol stack type in Content6 is selected as the negotiated protocol stack type.

The KMC may perform a KMIP session with the client device by using the protocol stack type carried in the second negotiation response message when performing a KMIP session with the client device. The following describes an embodiment in which the first negotiation device is a KMC, that is, a negotiation request is initiated by the KMC.

As shown in FIG. 8 , another embodiment of the method for negotiating a protocol stack type of the present invention is: in this embodiment, the first negotiation device is a KMC, and the second negotiation device is a client device, where the client device unilaterally selects a protocol stack type. Then, the selected protocol stack type is sent to the KMC, and the information transmitted by the protocol stack type is encrypted and decrypted by using the public and private keys set by the KMC. The specific processing flow is as follows:

Step 801: The KMC encrypts the negotiation request message to be sent by using the KMC private key.

In the embodiment of the present invention, the negotiation request message may carry only all the protocol stack types supported by the KMC, and may further carry the priority corresponding to each protocol stack type set by the KMC.

Step 802: The KMC sends the negotiation request message encrypted in step 801 to the client device.

Step 803: The client device decrypts the received encrypted negotiation request message by using the KMC public key.

Step 804: The client device determines, according to all protocol stack types supported by the KMC carried in the negotiation request message, all protocol stack types supported by the KMC and the client device, in combination with all protocol stack types supported by the client device.

Step 805: The client device selects a protocol stack type from all the protocol stack types supported by the determined KMC and the client device.

The client device may select a protocol stack type by using any one of the following methods: From the protocol stack types supported by the KMC and the client device, randomly select a protocol stack type; according to a protocol preset by the client device The stack type priority, from all the protocol stack types supported by the KMC and the client device, select a protocol stack type according to a preset policy; according to the protocol preset by the KMC carried in the received negotiation request message Stack type priority. From all protocol stack types supported by KMC and client devices, select a protocol stack type according to a preset policy.

Step 806: The client device encrypts the first negotiation response message to be sent by using the KMC public key. The first negotiation response message carries a protocol stack type selected in step 805.

Step 807: The client device sends the encrypted first negotiation response message to the KMC.

Step 808: The KMC decrypts the received encrypted first negotiation response message by using the KMC private key. The KMC can obtain a protocol stack type supported by the client device and the KMC jointly supported by the client device from the first negotiation response message, and the KMC can use the protocol stack type to perform a KMIP session with the client device.

In addition, when the information transmitted by the protocol stack type is encrypted and decrypted by using the public-private key mechanism, the main body of the public-private key pair may also be a client device, wherein the client device may pre-set the client public key and the client. End the private key, and publish the client public key, and save the client private key. The subsequent client device may encrypt the message to be sent to the KMC by using the client private key, and decrypt the message received from the KMC by using the client private key, and accordingly, the KMC utilizes the The client public key decrypts the message received from the client device and encrypts the message to be sent to the client device using the client public key. Specifically, the KMC encrypts the negotiation request message sent to the client device by using the client public key, and the client device decrypts the received encrypted negotiation request message by using the client private key; when the client device returns to the KMC When the first negotiation response message is used, the first negotiation response message to be sent by the client private key is encrypted, and the KMC decrypts the received encrypted first negotiation response message by using the client public key. As shown in FIG. 9 , another embodiment of the method for negotiating a protocol stack type according to the present invention is as follows: in this embodiment, the first negotiation device is a KMC, and the second negotiation device is a client device, where the client device and the KMC jointly select a protocol. The stack type uses the public-private key set by the client device to encrypt and decrypt the information transmitted during the negotiation of the protocol stack type. The specific processing flow is as follows:

Step 901: The KMC encrypts the negotiation request message to be sent by using the client public key, and the negotiation request message carries all protocol stack types supported by the KMC.

In the embodiment of the present invention, when there are multiple client devices that need to perform a KMIP session with the KMC respectively, each client device may separately set a client public key and a client private key, and advertise the client public key, and save the client. The private key, after receiving the client public key published by the client device, the KMC can contact the client public key with the client. The identifier of the client device is correspondingly stored, so that the client corresponding to the identifier of the client device is found in the correspondence between the pre-stored client public key and the identifier of the client device when the client device performs protocol stack type negotiation. The public key, and the negotiation request message to be sent is encrypted by the found client public key.

Step 902: The KMC sends the negotiation request message encrypted in step 901 to the client device.

Step 903: The client device decrypts the received encrypted negotiation request message by using the client private key.

Step 904: The client device selects all protocol stack types supported by the KMC and the client device according to all protocol stack types supported by the KMC carried by the negotiation request message and all protocol stack types supported by the client device.

Step 905: The client device encrypts the first negotiation response message to be sent by using the client private key, where the first negotiation response message carries all protocol stack types supported by the KMC and the client device.

In the embodiment of the present invention, the first negotiation response message may only carry all the protocol stack types supported by the KMC and the client device, and may further carry the priority corresponding to each protocol stack type set by the client device.

In addition, the first negotiation response message may also carry only all protocol stack types supported by the client device, and may be combined with the KMC itself according to all protocol stack types supported by the client device carried by the first negotiation response message. All the types of protocol stacks supported by the KMC and the client device are selected. The first negotiation response message may further carry the priority corresponding to each protocol stack type set by the client device.

Step 906: The client device sends the encrypted first negotiation response message to the KMC.

Step 907: The KMC decrypts the received encrypted first negotiation response message by using the client public key.

The KMC and the client device can support only one protocol type or multiple. When the KMC and the client device support more than one protocol stack type, the KMC can also support the KMC and the client device. In all the protocol stack types, a protocol stack type is pre-selected, and the subsequent KMC performs a KMIP session with the client device by using the selected protocol stack type when performing a KMIP session with the client device. Therefore, the present invention implements The example also includes a plurality of optional steps, as follows step 908 to step 911.

Step 908: The KMC selects a protocol stack type from all protocol stack types supported by the KMC and the client device carried by the first negotiation response message.

The KMC may select any of the following methods when selecting the protocol stack type: From the protocol stack types supported by the KMC and the client device, a protocol stack type is randomly selected; according to the KMC Pre-set protocol stack type priority, from all protocol stack types supported by the KMC and the client device, selecting a protocol stack type according to a preset policy; according to the received first negotiation response message The pre-set protocol stack type priority of the client device. From all protocol stack types supported by the KMC and the client device, a protocol stack type is selected according to a preset policy.

Step 909: The KMC encrypts the second negotiation response message to be sent by using the client public key, and the second negotiation response message carries a protocol stack type selected by step 908.

Step 910: The KMC sends the encrypted second negotiation response message to the client device.

Step 911: The client device decrypts the encrypted second negotiation response message by using the client private key, and then the client device uses the protocol stack type carried in the second negotiation response message when performing KMIP session with the KMC. A KMIP session with the KMC.

In addition, when the public-private key mechanism is used to encrypt and decrypt the information transmitted during the negotiation of the protocol stack type, the main body of the public-private key pair may also be a KMC. The specific encryption and decryption processing will not be repeated here. As shown in FIG. 10, the protocol stack type negotiation method of the present invention is another embodiment. In this embodiment, the first negotiation device is a KMC, and the second negotiation device is a client device, where the client device unilaterally selects a protocol stack type. Then, the selected protocol stack type is sent to the KMC, and the information transmitted by the protocol stack type is encrypted and decrypted by using the symmetric key, and the random number enhanced encryption and decryption robustness is introduced to ensure the protocol stack type negotiation process information. It has not been tampered with, and its specific processing flow is as follows:

Step 1001: The KMC shares the symmetric key Key with both client devices.

Step 1002: The KMC sends a negotiation request message to the client device.

In the embodiment of the present invention, the negotiation request message carries two parts of content: Contentl, Content2

Contentl can contain only all the protocol stack types supported by the KMC itself, and can further include the priority corresponding to each protocol stack type set by the KMC.

Content2 is the ciphertext output obtained after executing the encryption function encryptFunc (KMCRandl , Contentl , Key). The parameter KMCRandl is a random number generated by KMC. It is the same as the parameter Contentl as the plaintext input in the encryption algorithm. The parameter Key is the symmetric key Key in step 1001, and is used as the encryption key in the function encryptFunc.

Step 1003: The client device determines the validity of the negotiation request message.

The client device first performs a decryption function decryptFunc (Content2, Key carried in step 1002) to obtain a plaintext output. The parameter Key is the symmetric key Key in step 1001 and is used as the decryption key in the function decryptFunc. If the decryption fails, indicating that the negotiation request message is invalid (may have been tampered with), then the end Negotiation. If the decryption is successful, get KMCRandl ' , Content 1 '. The client device compares Contentl ' with Contentl carried in step 1002. If the two are inconsistent, indicating that the negotiation request message is invalid (may have been tampered with), the negotiation is terminated. If the two are consistent, indicating that the negotiation request message is valid, continue to negotiate.

Step 1004: The client device determines, according to all protocol stack types supported by the KMC in Contentl carried in the negotiation request message, and all protocol stack types supported by the client device, to determine all protocol stack types supported by the KMC and the client device. .

Step 1005: The client device selects a protocol stack type from all protocol stack types supported by the determined KMC and the client device.

The client device may select a protocol stack type in any of the following ways: From all protocol stack types supported by the KMC and the client device, randomly select a protocol stack type; according to a protocol stack preset by the client device. Type priority, from all protocol stack types supported by the KMC and the client device, select a protocol stack type according to a preset policy, for example, preset a protocol stack type with the highest priority, or preset Select a protocol stack type with the lowest priority; from all the protocol stack types supported by the KMC and the client device, select a protocol stack type priority set by the KMC carried in the negotiation request message, and select one according to a preset policy. The protocol stack type, for example, is preset to select a protocol stack type with the highest priority, or preset to select a protocol stack type with the lowest priority.

Step 1006: The client device sends a first negotiation response message to the KMC, where the first negotiation response message carries two parts: Content3, Content4.

Content3 is a protocol stack type selected in step 1005.

Content4 is the ciphertext output obtained by executing the encryption function encryptFunc (random number combination, Content3, Key). The parameter "random number combination" may only include the KMCRandl ' decrypted in step 1103, and may further include a random number ClientRandl generated by the client device. Two random numbers can be combined by means of / or / connection. The "random number combination" is the same as the plaintext input in the encryption algorithm, and the parameter Key is the symmetric key Key in step 1001, and is used as the encryption key in the function encryptFunc.

Step 1007: The KMC determines the validity of the first negotiation response message.

The KMC first performs a decryption function decryptFunc (Content4, Key carried in step 1006) to obtain a plaintext output. If the decryption fails, indicating that the first negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the decryption is successful, get the random number combination ', Content3'. The KMC then compares Content3' with Content3 carried in step 1006. If the two are inconsistent, indicating that the first negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the two are consistent, indicating that the first negotiation response message is valid, the protocol stack type in Content3 is selected as the negotiated protocol stack type. As shown in FIG. 11, another embodiment of the method for negotiating a protocol stack type is the same. In this embodiment, the first negotiation device is a KMC, and the second negotiation device is a client device, where the client device and the KMC jointly select a protocol. The stack type, and then the KMC sends the finally selected protocol stack type to the client device, and uses the symmetric key to encrypt and decrypt the information transmitted during the protocol stack type negotiation, and introduces random number enhancement encryption and decryption robustness. To ensure that the protocol stack negotiation process information has not been tampered with, the specific processing procedure is as follows: Step 1101: The KMC and the client device share the symmetric key Key.

Step 1102: The KMC sends a negotiation request message to the client device.

Content2 is the ciphertext output obtained after executing the encryption function encryptFunc (KMCRandl , Contentl , Key). The parameter KMCRandl is a random number generated by KMC, which is the same as the parameter Contentl as the plaintext input in the encryption algorithm. The parameter Key is the symmetric key Key in step 1101, and is used as the encryption key in the function encryptFunc.

Step 1103: The client determines the validity of the negotiation request message.

The client device first performs a decryption function decryptFunc (Content2, Key carried in step 1102) to obtain a plaintext output. The parameter Key is the symmetric key Key in step 1101 and is used as the decryption key in the function decryptFunc. If the decryption fails, indicating that the negotiation request message is invalid (may have been tampered with), the negotiation is terminated. If the decryption is successful, get KMCRandl ' , Contentl '. The client device then compares Contentl ' with the Contentl carried in step 1102. If the two are inconsistent, indicating that the negotiation request message is invalid (may have been tampered with), the negotiation is terminated. If the two are consistent, indicating that the negotiation request message is valid, continue to negotiate.

Step 1104: The client device selects all protocol stack types supported by the KMC and the client device according to all protocol stack types supported by the KMC in the Contentl carried in the negotiation request message, and all protocol stack types supported by the client device. .

Step 1105: The client device sends a first negotiation response message to the KMC.

In the embodiment of the present invention, the first negotiation response message carries two parts of content: Content3, Content4. Content3 can contain only all protocol stack types supported by the KMC and the client device, and can further include the priority corresponding to each protocol stack type set by the client device.

Content4 is the ciphertext output obtained after executing the encryption function encryptFunc (random number combination, Content3, Key). The parameter "random number combination" may include only the KMCRandl ' decrypted in step 1103, and may further include a random number ClientRand1 generated by the client device. Two random numbers can pass and / or / A combination of connections and the like. The "random number combination" is the same as the plaintext input in the encryption algorithm, and the parameter Key is the symmetric key Key in step 1101, and is used as the encryption key in the function encryptFunc.

In addition, the Cont _en t3 in the first negotiation response message may also carry only all protocol stack types supported by the client device, and may be combined by the KMC according to all protocol stack types supported by the client device carried by the first negotiation response message. The protocol stack type supported by the KMC itself is selected by the protocol stack type supported by the KMC and the client device. The Cont _en t3 in the first negotiation response message may further carry the protocol stack type corresponding to the client device. priority.

The KMC and the client device can support only one protocol type or multiple. When the KMC and the client device support more than one protocol stack type, the KMC can also support the KMC and the client device. In all the protocol stack types, a protocol stack type is pre-selected, and the subsequent KMC performs a KMIP session with the client device by using the selected protocol stack type when performing a KMIP session with the client device. Therefore, the present invention implements The example also includes a plurality of optional steps, as follows, step 1107, step 1108, and step 1109.

Step 1106: The KMC determines the validity of the first negotiation response message.

The KMC first performs the decryption function decryptFunc (Content4, Key carried in step 1105) to obtain the plaintext output. If the decryption fails, indicating that the first negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the decryption is successful, get the random number combination ', Content3'. The KMC then compares Content3' with the Content3 carried in step 1105. If the two are inconsistent, indicating that the first negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the two are consistent, indicating that the first negotiation response message is valid, continue to negotiate.

Step 1107: The KMC selects a protocol stack type from all protocol stack types supported by the KMC and the client device carried by the first negotiation response message.

When the KMC selects the protocol stack type, it can adopt any of the following selection methods: From the protocol stack types supported by the KMC and the client device, a protocol stack type is randomly selected; according to the protocol stack type preset by the KMC Priority, from all the protocol stack types supported by the KMC and the client device, select a protocol stack type according to a preset policy, for example, preset a protocol stack type with the highest priority, or preset Selecting a protocol stack type with the lowest priority; according to the protocol stack type priority preset by the client device carried in the received first negotiation response message, from all protocol stack types supported by the KMC and the client device Select a protocol stack type according to a preset policy, for example, pre-set to select a protocol stack type with the highest priority, or pre-set to select a protocol stack type with the lowest priority. Step 1108: The KMC sends a second negotiation response message to the client device, where the second negotiation response message carries two parts: Content5, Content6.

Content5 is a protocol stack type selected in step 1107.

Content6 is the ciphertext output obtained by executing the encryption function encryptFunc (random number combination, Content5, Key). The parameter "random number combination" may include only the KMCRand1 in the negotiation request message, or only the KMC regenerated KMCRand2, and may further include the random number ClientRand1 generated by the client device in Content1 in step 1105. Two random numbers can be combined by means of / or / connection. The "random number combination" and Cont _en t5 are the plaintext input in the encryption algorithm, and the parameter Key is the symmetric key Key in step 1101, and is used as the encryption key in the function encryptFunc.

Step 1109: The client device determines validity of the second negotiation response message.

The client device first performs a decryption function decryptFunc (Content6, Key carried in step 1108) to obtain a plaintext output. If the decryption fails, indicating that the second negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the decryption is successful, get the random number combination ', Contents'. The client device compares the Contents ' with the Content5 carried in step 1108. If the two are inconsistent, indicating that the second negotiation response message is invalid (may have been tampered with), the negotiation is terminated. If the two are consistent, indicating that the second negotiation response message is valid, the protocol stack type in Contents is selected as the negotiated protocol stack type. The client device may perform a KMIP session with the KMC by using the protocol stack type carried in the second negotiation response message when performing a KMIP session with the KMC. Corresponding to the embodiment of the protocol stack type negotiation method of the present invention, the present invention also provides an embodiment of the protocol stack type negotiation apparatus.

An embodiment of the protocol stack type negotiation device of the present invention is shown in FIG. 12, where the device is configured in a first negotiation device that performs protocol stack type negotiation with the second negotiation device, and includes:

The negotiation request message sending unit 1201 is configured to send a negotiation request message to the second negotiation device, where the negotiation request message carries the protocol stack type supported by the first negotiation device, so that the second negotiation device is configured according to the Selecting a protocol stack type supported by the first negotiation device that is carried in the negotiation request message, and selecting a protocol stack type supported by the second negotiation device and the first negotiation device;

The first negotiation response message receiving unit 1202 is configured to receive a first negotiation response message that is sent by the second negotiation device according to the negotiation request message sent by the negotiation request message sending unit 1201;

The protocol stack type obtaining unit 1203 is configured to obtain, according to the first negotiation response message received by the first negotiation response message receiving unit 1202, a protocol stack supported by the second negotiation device and the first negotiation device. Types of.

With the protocol stack type negotiation device provided by the embodiment of the present invention, before the KMIP session with the KMC, the client device does not randomly select the protocol stack type to perform the KMIP session, but one party serves as the first negotiation device, and the other party acts as the second. The negotiation device sends a negotiation request message carrying the protocol stack type supported by the first negotiation device to the second negotiation device through the negotiation request message sending unit 1201 in the protocol stack type negotiation device, which is set in the first negotiation device, and then The first negotiation response message receiving unit 1202 receives the first negotiation response message fed back by the second negotiation device, and the protocol stack type obtaining unit 1203 obtains the protocol supported by the second negotiation device and the first negotiation device by using the first negotiation response message. The stack type, that is, the type of protocol stack that is supported by the KMC and the client device. It can be seen that, in the embodiment of the present invention, the protocol stack type negotiated by the first negotiation device and the second negotiation device is a protocol stack type supported by the second negotiation device and the first negotiation device, and therefore, the KMC and the client are subsequently When the device performs a KMIP session, the protocol stack type used by the two parties is the protocol stack type supported by the KMC and the client device. Therefore, both the KMC and the client device can correctly parse the received KMIP message; and, the client device and The KMC chooses the protocol stack type through auto-negotiation, so it does not need to be manually configured for easy maintenance.

In a specific embodiment of the foregoing protocol stack type negotiation apparatus of the present invention, the first negotiation response message received by the first negotiation response message receiving unit 1202 carries the second negotiation device and the two parties jointly support at least one protocol stack. Types of;

The protocol stack type obtaining unit 1203 is specifically configured to: select, from the first negotiation response message received by the first negotiation response message receiving unit 1202, one of the second negotiation device and the first negotiation device to support Protocol stack type.

Optionally, in the foregoing specific embodiment, the first negotiation response message received by the first negotiation response message receiving unit 1202 further carries a protocol stack type priority preset by the second negotiation device; The protocol stack type obtaining unit 1203 is specifically configured to: according to the protocol stack type priority set by the second negotiation device, the first negotiation response message received by the first negotiation response message receiving unit 1202 At least one protocol stack type supported by the two parties determined by the second negotiation device, and a protocol stack type supported by the second negotiation device and the first negotiation device is selected.

In another specific embodiment of the foregoing protocol stack type negotiation apparatus of the present invention, the negotiation request message sent by the negotiation request message sending unit 1201 further carries a protocol stack type priority set in advance by the first negotiation device;

The first negotiation response message received by the first negotiation response message receiving unit 1202 carries a protocol stack type supported by the two parties selected by the second negotiation device, where the two parties jointly support one protocol. The stack type is a protocol stack type supported by the first negotiation device and a protocol preset by the first negotiation device, which are carried by the second negotiation device according to the negotiation request message sent by the negotiation request message sending unit 1201. The stack type priority, the selected one of the protocol stack types supported by the second negotiation device and the first negotiation device.

In another specific embodiment of the protocol stack type negotiation apparatus of the present invention, the first negotiation response message received by the first negotiation response message receiving unit 1202 carries the protocol stack type supported by the second negotiation device;

The protocol stack type obtaining unit 1203 is specifically configured to: select, according to the protocol stack type supported by the second negotiation device, in the first negotiation response message received by the first negotiation response message receiving unit 1202, Negotiating the type of protocol stack supported by the device and the first negotiation device.

Optionally, in the foregoing specific embodiment, the first negotiation response message received by the first negotiation response message receiving unit 1202 further carries a protocol stack type priority preset by the second negotiation device;

The protocol stack type obtaining unit 1203 is specifically configured to: prior to the protocol stack type priority set by the second negotiation device carried in the first negotiation response message received by the first negotiation response message receiving unit 1202, Determining a protocol stack type supported by the second negotiation device, and determining a protocol stack type supported by the second negotiation device and the first negotiation device. As shown in FIG. 13 is another embodiment of the protocol stack type negotiation device of the present invention. The device is configured in a first negotiation device that performs protocol stack type negotiation with the second negotiation device, and includes:

The negotiation request message sending unit 1301 is configured to send a negotiation request message to the second negotiation device, where the negotiation request message carries the protocol stack type supported by the first negotiation device;

The first negotiation response message receiving unit 1302 is configured to receive a first negotiation response message that is sent by the second negotiation device according to the negotiation request message sent by the negotiation request message sending unit 1301;

a protocol stack type obtaining unit 1303, configured to obtain, according to the first negotiation response message received by the first negotiation response message receiving unit 1302, a protocol stack type supported by the second negotiation device and the first negotiation device;

The second negotiation response message sending unit 1304 is configured to send a second negotiation response message to the second negotiation device, where the second negotiation response message carries a protocol stack type commonly supported by the two parties selected by the first negotiation device. FIG. 14 is another embodiment of a protocol stack type negotiation apparatus according to the present invention, where the apparatus is disposed in The first negotiation device that negotiates the protocol stack type by the second negotiation device includes:

The key interaction unit 1401 is configured to exchange key information with the second negotiation device before the negotiation request message sending unit 1402 sends the negotiation request message to the second negotiation device, so that the first negotiation device and the device The second negotiation device uses the public-private key encryption and decryption mechanism to perform protocol stack type negotiation according to the key information. The negotiation request message sending unit 1402 is configured to send, according to the key interaction unit, the second negotiation device.

The negotiation request message after the encrypted key information is encrypted, where the negotiation request message carries the protocol stack type supported by the first negotiation device;

The first negotiation response message receiving unit 1403 is configured to receive the encrypted first negotiation response message that is fed back by the second negotiation device according to the negotiation request message, and the key information pair that is exchanged according to the key interaction unit 1401. Decrypting the encrypted first negotiation response message to obtain a first negotiation response message; the protocol stack type obtaining unit 1404 is configured to obtain, according to the first negotiation response message received by the first negotiation response message receiving unit 1403, The protocol stack type supported by the second negotiation device and the first negotiation device.

In an embodiment of the key interaction unit 1401, the key interaction unit 1401 specifically includes: a key setting subunit, configured to advance the negotiation request message sending unit 1402 before sending the negotiation request message to the second negotiation device. Setting a first negotiation device private key and a first negotiation device public key;

a private key storage sub-unit, configured to store a first negotiation device private key set by the key setting sub-unit; a public key sending sub-unit, configured to set the first negotiation device set by the key setting sub-unit Sending a key to the second negotiation device;

The negotiation request message sending unit 1402 is specifically configured to send, to the second negotiation device, the negotiation request message that is encrypted by the first negotiation device private key stored by the private key storage subunit, where the negotiation request message is included. Carrying all protocol stack types supported by the first negotiation device;

The first negotiation response message receiving unit 1403 is configured to receive, after the second negotiation device encrypts, the first negotiation device public key that is sent by the public key sending subunit, according to the negotiation request message, a negotiation response message, the first negotiation response message carries a protocol stack type supported by the second negotiation device, and the first negotiation device private key stored by the private key storage subunit is used to encrypt the The first negotiation response message is decrypted to obtain a first negotiation response message.

In another embodiment of the key interaction unit 1401, the key interaction unit 1401 is specifically configured to: before the negotiation request message sending unit 1402 sends a negotiation request message to the second negotiation device, obtain the second negotiation device to preset The second negotiated device public key.

The negotiation request message sending unit 1402 is specifically configured to acquire the information from the key interaction unit 1401. The second negotiation device public key, and the negotiation request message that is encrypted by the second negotiation device public key is sent to the second negotiation device, where the negotiation request message carries all the protocols supported by the first negotiation device. Stack type

The first negotiation response message receiving unit 1403 is configured to receive, by the second negotiation device, a first negotiation response message that is encrypted by the second negotiation device private key, which is fed back according to the negotiation request message, the first negotiation The response message carries the protocol stack type supported by the second negotiation device, and decrypts the encrypted first negotiation response message by using the second negotiation device public key acquired by the key interaction unit 1401. , get the first negotiation response message. As shown in FIG. 15, another embodiment of the protocol stack type negotiation apparatus of the present invention is provided, where the apparatus is configured in a first negotiation device that performs protocol stack type negotiation with the second negotiation device, and includes:

a key sharing unit 1501, configured to share a symmetric key with the second negotiation device;

The encryption unit 1502 is configured to send, by the first negotiation device, the symmetric key shared by the key sharing unit 1501 and the obtained random number pair to the second negotiation device before sending the message to the second negotiation device. The message is encrypted to obtain a message ciphertext;

The negotiation request message sending unit 1503 is configured to send a negotiation request message to the second negotiation device, where the negotiation request message carries the protocol stack type supported by the first negotiation device, so that the second negotiation device is configured according to the Selecting a protocol stack type supported by the first negotiation device that is carried in the negotiation request message, and selecting a protocol stack type supported by the second negotiation device and the first negotiation device;

The ciphertext sending unit 1504 is configured to send the message ciphertext obtained by the encryption unit 1502 at the same time when the message is sent, so that the second negotiation device decrypts the received message ciphertext to obtain a message plaintext. Comparing the plaintext of the message with the received message, and continuing the protocol stack type negotiation when the comparison result is the same;

The first negotiation response message receiving unit 1505 is configured to receive a first negotiation response message that is sent by the second negotiation device according to the negotiation request message sent by the negotiation request message sending unit 1503.

The decryption unit 1506 is configured to: after the first negotiation device receives the message ciphertext sent by the second negotiation device while sending the message, pair the message ciphertext according to the symmetric key shared by the key sharing unit 1501 Decrypting, obtaining a message plaintext, wherein the message ciphertext is that the second negotiation device encrypts the message sent to the first negotiation device according to the symmetric key and the obtained random number, and the obtained message is obtained. The ciphertext comparison unit 1507 is configured to compare the message plaintext obtained by the decryption unit 1506 with the received message, and continue to perform protocol stack type negotiation when the comparison result is the same; The protocol stack type obtaining unit 1508 is configured to obtain, according to the first negotiation response message received by the first negotiation response message receiving unit 1505, a protocol stack type supported by the second negotiation device and the first negotiation device. As shown in FIG. 16 is another embodiment of the protocol stack type negotiation device of the present invention. The device is configured in a second negotiation device that performs protocol stack type negotiation with the first negotiation device, and includes:

The negotiation request message receiving unit 1601 is configured to receive a negotiation request message sent by the first negotiation device, where the negotiation request message carries a protocol stack type supported by the first negotiation device;

The protocol stack type obtaining unit 1602 is configured to select, according to the protocol stack type supported by the first negotiation device that is carried in the negotiation request message received by the negotiation request message receiving unit 1601, the second negotiation device and the first a protocol stack type that is commonly supported by the negotiation device;

The first negotiation response message sending unit 1603 is configured to feed back a first negotiation response message to the first negotiation device according to the negotiation request message received by the negotiation request message receiving unit 1601, so that the first negotiation device is configured according to the The first negotiation response message obtains a protocol stack type supported by the second negotiation device and the first negotiation device.

In a specific embodiment of the protocol stack type negotiation apparatus of the present invention, the first negotiation response message sent by the first negotiation response message sending unit 1603 carries the protocol stack type supported by the second negotiation device, And causing the first negotiation device to select a protocol stack type supported by the second negotiation device and the first negotiation device according to the protocol stack type supported by the second negotiation device that is carried in the first negotiation response message .

Optionally, in the foregoing specific embodiment, the first negotiation response message sent by the first negotiation response message sending unit 1603 further carries a protocol stack type priority preset by the second negotiation device, so that Determining, by the first negotiation device, a second negotiation according to a protocol stack type priority preset by the second negotiation device and a protocol stack type supported by the second negotiation device, which are carried in the first negotiation response message. The type of protocol stack supported by the device and the first negotiation device. As shown in FIG. 17, another embodiment of the protocol stack type negotiation apparatus of the present invention is provided, where the apparatus is disposed in a second negotiation device that performs protocol stack type negotiation with the first negotiation device, and includes:

The negotiation request message receiving unit 1701 is configured to receive a negotiation request message sent by the first negotiation device, where the negotiation request message carries a protocol stack type supported by the first negotiation device;

a protocol stack type obtaining unit 1702, configured to receive according to the negotiation request message receiving unit 1701 Selecting a protocol stack type supported by the first negotiation device that is carried in the negotiation request message, and selecting a protocol stack type supported by the second negotiation device and the first negotiation device;

The protocol stack type determining unit 1703 is configured to determine at least one protocol stack type that is supported by the two parties. The first negotiation response message sending unit 1704 is configured to send, according to the negotiation request message received by the negotiation request message receiving unit 1701, the first The negotiation device feeds back a first negotiation response message, where the first negotiation response message carries at least one protocol stack type that is jointly supported by the protocol stack type determining unit 1703, so that the first negotiation device is In the first negotiation response message, a protocol stack type supported by the second negotiation device and the first negotiation device is selected.

In a specific embodiment of the protocol stack type negotiation apparatus of the present invention, the first negotiation response message sent by the first negotiation response message sending unit 1704 further carries a protocol stack type preset by the second negotiation device. a priority level, so that the first negotiation device supports the two mutually agreed by the second negotiation device that is carried in the first negotiation response message according to the protocol stack type priority set by the second negotiation device. At least one protocol stack type, selecting a protocol stack type supported by the second negotiation device and the first negotiation device. As shown in FIG. 18, another embodiment of the protocol stack type negotiation device of the present invention is provided. The device is configured in a second negotiation device that performs protocol stack type negotiation with the first negotiation device, and includes:

The negotiation request message receiving unit 1801 is configured to receive a negotiation request message sent by the first negotiation device, where the negotiation request message carries a protocol stack type supported by the first negotiation device and a protocol preset by the first negotiation device. Stack type priority;

a protocol stack type obtaining unit 1802, configured to select, according to all protocol stack types supported by the first negotiation device that are carried in the negotiation request message received by the negotiation request message receiving unit 1801, the second negotiation device and the The type of protocol stack supported by the first negotiation device;

The selecting unit 1803 is configured to select one of the second negotiation devices according to the protocol stack type supported by the first negotiation device and the protocol stack type priority set by the first negotiation device that are carried in the negotiation request message. a protocol stack type supported by the first negotiation device;

The first negotiation response message sending unit 1804 is configured to feed back a first negotiation response message to the first negotiation device according to the negotiation request message received by the negotiation request message receiving unit 1801, where the first negotiation response message carries Another type of protocol stack supported by the two selected by the selecting unit 1803. As shown in FIG. 19, another embodiment of the protocol stack type negotiating apparatus of the present invention is provided. The second negotiation device that negotiates the protocol stack type by the first negotiation device includes:

The negotiation request message receiving unit 1901 is configured to receive a negotiation request message sent by the first negotiation device, where the negotiation request message carries a protocol stack type supported by the first negotiation device;

The protocol stack type obtaining unit 1902 is configured to select, according to the protocol stack type supported by the first negotiation device that is carried in the negotiation request message received by the negotiation request message receiving unit 1901, the second negotiation device and the first a protocol stack type that is commonly supported by the negotiation device;

The first negotiation response message sending unit 1903 is configured to feed back a first negotiation response message to the first negotiation device according to the negotiation request message received by the negotiation request message receiving unit 1901, so that the first negotiation device is configured according to the a first negotiation response message, obtaining a protocol stack type supported by the second negotiation device and the first negotiation device;

The second negotiation response message receiving unit 1904 is configured to receive a second negotiation response message sent by the first negotiation device, where the second negotiation response message carries a protocol stack jointly supported by the first selected device by the first negotiation device. Types of. As shown in FIG. 20, another embodiment of the protocol stack type negotiation apparatus of the present invention is provided. The apparatus is configured in a second negotiation device that performs protocol stack type negotiation with the first negotiation device, and includes:

The key interaction unit 2001 is configured to: before the negotiation request message receiving unit 2002 receives the negotiation request message sent by the first negotiation device, exchange key information with the first negotiation device, so that the first negotiation device and the The second negotiating device performs protocol stack type negotiation by using a public-private key encryption and decryption mechanism according to the key information.

The negotiation request message receiving unit 2002 is configured to receive a negotiation request message that is encrypted by the key information exchanged by the key interaction unit 2001 and sent by the first negotiation device, and use the key information to perform the encrypted negotiation request. The message is decrypted to obtain a negotiation request message;

The protocol stack type obtaining unit 2003 is configured to select the second negotiation device and the first according to the protocol stack type supported by the first negotiation device that is carried in the negotiation request message received by the negotiation request message receiving unit 2002. Negotiating the type of protocol stack supported by the device;

The first negotiation response message sending unit 2004 is configured to feed back, to the first negotiation device, a first negotiation response message that is encrypted according to the key information exchanged by the key interaction unit 2001, so that the first negotiation device is configured according to the first negotiation device. The first negotiation response message obtains a protocol stack type supported by the second negotiation device and the first negotiation device.

In an embodiment of the key interaction unit 2001, the key interaction unit 2001 specifically includes: a key setting subunit, configured to preset a second negotiation device private key and a second negotiation device public key before the negotiation request message receiving unit 2002 receives the negotiation request message sent by the first negotiation device;

a private key storage subunit, configured to store a second negotiating device private key set by the key setting subunit; a public key sending subunit, configured to set a second negotiating device set by the key setting subunit The key is sent to the first negotiation device.

In another embodiment of the key interaction unit 2001, the key interaction unit 2001 is specifically configured to: obtain the first negotiation device in advance before the negotiation request message receiving unit 2002 receives the negotiation request message sent by the first negotiation device. The first negotiated device public key is set. As shown in FIG. 21, another embodiment of the protocol stack type negotiation device of the present invention is provided. The device is configured in a second negotiation device that performs protocol stack type negotiation with the first negotiation device, and includes:

a key sharing unit 2101, configured to share a symmetric key with the first negotiation device;

The negotiation request message receiving unit 2102 is configured to receive a negotiation request message sent by the first negotiation device, where the negotiation request message carries a protocol stack type supported by the first negotiation device;

The decryption unit 2103 is configured to: after the second negotiation device receives the message ciphertext sent by the first negotiation device while sending the message, pair the message ciphertext according to the symmetric key shared by the key sharing unit 2101 Decrypting, obtaining a message plaintext, wherein the message ciphertext is that the first negotiation device encrypts a message sent to the first negotiation device according to the symmetric key and the obtained random number, and the obtained message is obtained. The ciphertext comparison unit 2104 is configured to compare the message plaintext obtained by the decryption unit 2103 with the received message, and continue to perform protocol stack type negotiation when the comparison result is the same;

The protocol stack type obtaining unit 2105 is configured to select, according to the protocol stack type supported by the first negotiation device that is carried in the negotiation request message received by the negotiation request message receiving unit 2102, the second negotiation device and the first a protocol stack type that is commonly supported by the negotiation device;

The encryption unit 2106 is configured to send, by the second negotiation device, the symmetric key shared by the key sharing unit 2101 and the obtained random number pair to the first negotiation device before sending the message to the first negotiation device. The message is encrypted to obtain a message ciphertext;

The first negotiation response message sending unit 2107 is configured to feed back the first negotiation response message to the first negotiation device, so that the first negotiation device obtains the second negotiation device according to the first negotiation response message. a protocol stack type commonly supported by the first negotiation device;

The ciphertext sending unit 2108 is configured to send the message ciphertext obtained by the encryption unit 2106 at the same time when the message is sent, so that the first negotiation device decrypts the received message ciphertext to obtain a message plaintext. The plaintext of the message is compared with the received message, and when the comparison result is the same, the protocol stack type negotiation is continued.

A person skilled in the art will further appreciate that the elements and algorithm steps of the various examples described in connection with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both, in order to clearly illustrate hardware and software. Interchangeability, the composition and steps of the various examples have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the solution. A person skilled in the art can use different methods to implement the described functions for each particular application, but such implementation should not be considered to be beyond the scope of the embodiments of the invention.

The steps of a method or algorithm described in connection with the embodiments disclosed herein can be implemented directly in hardware, a software module executed by a processor, or a combination of both.

The above description of the disclosed embodiments enables those skilled in the art to make or use the embodiments of the invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the embodiments of the invention. . Therefore, the embodiments of the invention are not to be limited to the embodiments shown herein, but are to be accorded to the broadest scope of the principles and novel features disclosed herein.

The above are only the preferred embodiments of the present invention, and are not intended to limit the embodiments of the present invention, and any modifications, equivalents, improvements, etc. made within the spirit and principles of the embodiments of the present invention are It should be included in the scope of protection of the embodiments of the present invention.

Claims

Rights request

A protocol stack type negotiation method, which is characterized in that:

The first negotiation device sends a negotiation request message to the second negotiation device, where the negotiation request message carries the protocol stack type supported by the first negotiation device, so that the second negotiation device carries the message according to the negotiation request message. The protocol stack type supported by the first negotiation device, and the protocol stack type supported by the second negotiation device and the first negotiation device are selected;

Receiving a first negotiation response message that is sent by the second negotiation device according to the negotiation request message; and obtaining, according to the first negotiation response message, a protocol stack type supported by the second negotiation device and the first negotiation device .

2. The method of claim 1 wherein

The first negotiation response message carries at least one protocol stack type jointly supported by the two parties determined by the second negotiation device;

And obtaining, according to the first negotiation response message, a protocol stack type supported by the second negotiation device and the first negotiation device, including:

And selecting, by the first negotiation response message, a protocol stack type supported by the second negotiation device and the first negotiation device.

The method according to claim 2, wherein the first negotiation response message further carries a protocol stack type priority preset by the second negotiation device;

Selecting, according to the protocol stack type priority set by the second negotiation device, at least one protocol stack type jointly supported by the second negotiation device carried in the first negotiation response message, selecting one The protocol stack type supported by the second negotiation device and the first negotiation device.

4. The method of claim 1 wherein:

The negotiation request message further carries a protocol stack type priority set by the first negotiation device; the first negotiation response message carries a protocol stack type commonly supported by the two selected devices by the second negotiation device, where A protocol stack type that is jointly supported by the two parties is that the second negotiation device takes precedence according to the protocol stack type supported by the first negotiation device and the protocol stack type preset by the first negotiation device that are carried in the negotiation request message. Level, the selected one of the protocol stack types supported by the second negotiation device and the first negotiation device.

The method according to claim 1, wherein the first negotiation response message carries a protocol stack type supported by the second negotiation device;

Determining, according to the protocol stack type supported by the second negotiation device that is carried in the first negotiation response message, a protocol stack type supported by the second negotiation device and the first negotiation device.

The method according to claim 5, wherein the first negotiation response message further carries a protocol stack type priority preset by the second negotiation device;

Determining, according to the protocol stack type priority preset by the second negotiation device that is carried in the first negotiation response message, and the protocol stack type supported by the second negotiation device, determining the second negotiation device and the The protocol stack type supported by the first negotiation device.

The method according to any one of claims 1 to 6, wherein the method further comprises:

And sending, by the second negotiation device, a second negotiation response message, where the second negotiation response message carries a protocol stack type supported by the two parties finally selected by the first negotiation device.

The method according to any one of claims 1 to 7, wherein before the sending, by the first negotiation device, the negotiation request message to the second negotiation device, the method further includes:

The key information is exchanged with the second negotiation device, so that the first negotiation device and the second negotiation device perform protocol stack type negotiation by using a public-private key encryption and decryption mechanism according to the key information.

The method according to any one of claims 1 to 7, further comprising: before the first negotiation device sends a negotiation request message to the second negotiation device, sharing with the second negotiation device Symmetric key

Before sending the message to the second negotiation device, the first negotiation device encrypts the message sent to the second negotiation device according to the symmetric key and the obtained random number, obtains the message ciphertext, and sends the message Sending the message ciphertext at the same time, so that the second negotiation device decrypts the received message ciphertext to obtain a message plaintext, and compares the message plaintext with the received message, when comparing the result When the same, continue the protocol stack type negotiation;

Receiving, by the first negotiation device, a message ciphertext sent by the second negotiation device while sending the message After the ciphertext is decrypted according to the symmetric key, the message plaintext is obtained, and the plaintext of the message is compared with the received message. When the comparison result is the same, the protocol stack type negotiation is continued, where The message ciphertext is used by the second negotiation device to encrypt the message sent to the first negotiation device according to the symmetric key and the obtained random number, and the obtained message ciphertext.

A protocol stack type negotiation device, wherein the device is configured in a first negotiation device that negotiates a protocol stack with the second negotiation device, and is characterized by:

a negotiation request message sending unit, configured to send a negotiation request message to the second negotiation device, where the negotiation request message carries a protocol stack type supported by the first negotiation device, so that the second negotiation device is configured according to the negotiation a protocol stack type supported by the first negotiation device that is carried in the request message, and a protocol stack type supported by the second negotiation device and the first negotiation device is selected;

a first negotiation response message receiving unit, configured to receive a first negotiation response message that is sent by the second negotiation device according to the negotiation request message sent by the negotiation request message sending unit;

And a protocol stack type obtaining unit, configured to obtain, according to the first negotiation response message received by the first negotiation response message receiving unit, a protocol stack type supported by the second negotiation device and the first negotiation device.

11. Apparatus according to claim 10 wherein:

The first negotiation response message received by the first negotiation response message receiving unit carries at least one protocol stack type jointly supported by the two parties determined by the second negotiation device;

The protocol stack type obtaining unit is configured to: select, from the first negotiation response message received by the first negotiation response message receiving unit, a protocol supported by the second negotiation device and the first negotiation device Stack type.

12. Apparatus according to claim 11 wherein:

The first negotiation response message received by the first negotiation response message receiving unit further carries a protocol stack type priority preset by the second negotiation device;

The protocol stack type obtaining unit is specifically configured to: according to the protocol stack type priority set by the second negotiation device, the first negotiation response message received by the first negotiation response message receiving unit At least one protocol stack type supported by the two parties determined by the second negotiation device, and a protocol stack type supported by the second negotiation device and the first negotiation device is selected.

13. Apparatus according to claim 10 wherein:

The negotiation request message sent by the negotiation request message sending unit further carries a protocol stack type priority preset by the first negotiation device;

The first negotiation response message received by the first negotiation response message receiving unit carries a protocol stack type supported by the two parties selected by the second negotiation device, where one protocol stack type supported by the two parties is the The second negotiation device selects a protocol stack type supported by the first negotiation device and a protocol stack type priority preset by the first negotiation device, which are carried in the negotiation request message sent by the negotiation request message sending unit. A protocol stack type supported by the second negotiation device and the first negotiation device.

The apparatus according to claim 10, wherein the first negotiation response message received by the first negotiation response message receiving unit carries a protocol stack type supported by the second negotiation device; The type obtaining unit is specifically used for:

Selecting a protocol supported by the second negotiation device and the first negotiation device according to the protocol stack type supported by the second negotiation device that is carried in the first negotiation response message received by the first negotiation response message receiving unit Stack type.

15. Apparatus according to claim 14 wherein:

The protocol stack type obtaining unit is specifically configured to:

Determining a protocol stack type priority preset by the second negotiation device and a protocol stack type supported by the second negotiation device, which are carried in the first negotiation response message received by the first negotiation response message receiving unit The protocol stack type supported by the second negotiation device and the first negotiation device.

The device according to any one of claims 10 to 15, wherein the device further comprises:

The second negotiation response message sending unit is configured to send a second negotiation response message to the second negotiation device, where the second negotiation response message carries a protocol stack type supported by the two parties selected by the first negotiation device.

17. Apparatus according to any one of claims 10 to 16 further comprising:

a key interaction unit, configured to exchange key information with the second negotiation device before the negotiation request message sending unit sends the negotiation request message to the second negotiation device, so that the first negotiation device and the The second negotiating device performs protocol stack type negotiation by using a public-private key encryption and decryption mechanism according to the key information.

18. Apparatus according to any one of claims 10 to 16 further comprising:

a key sharing unit, configured to share a symmetric key with the second negotiation device before the negotiation request message sending unit sends the negotiation request message to the second negotiation device;

An encryption unit, configured to send, by the first negotiation device, a message sent to the second negotiation device according to the symmetric key shared by the key sharing unit and the obtained random number pair before sending the message to the second negotiation device Encryption to obtain a message ciphertext;

a ciphertext sending unit, configured to simultaneously send a message ciphertext obtained by the ciphering unit when the message is sent, so that the second negotiating device decrypts the received message ciphertext to obtain a message plaintext, The plaintext of the message is compared with the received message, and when the comparison result is the same, the protocol stack type negotiation is continued;

a decryption unit, configured to: after the first negotiation device receives the message ciphertext sent by the second negotiation device while sending the message, decrypt the message ciphertext according to the symmetric key shared by the key sharing unit Obtaining a message, wherein the message ciphertext is that the second negotiation device encrypts the message sent to the first negotiation device according to the symmetric key and the obtained random number, and the obtained message ciphertext ;

The comparing unit is configured to compare the plaintext of the message obtained by the decrypting unit with the received message, and when the comparison result is the same, continue the protocol stack type negotiation.

19. A protocol stack type negotiation method, comprising:

The second negotiation device receives the negotiation request message sent by the first negotiation device, where the negotiation request message carries the protocol stack type supported by the first negotiation device;

Determining, according to the protocol stack type supported by the first negotiation device that is carried in the negotiation request message, a protocol stack type supported by the second negotiation device and the first negotiation device;

And feeding back, by using the negotiation request message, the first negotiation response message to the first negotiation device, so that The first negotiation device obtains a protocol stack type supported by the second negotiation device and the first negotiation device according to the first negotiation response message.

The method according to claim 19, further comprising: before the feeding back the first negotiation response message to the first negotiation device according to the negotiation request message,

Determining at least one protocol stack type supported by both parties;

The first negotiation response message carries at least one protocol stack type supported by the two parties, so that the first negotiation device selects one of the second negotiation device from the first negotiation response message, and the The protocol stack type supported by the first negotiation device.

21. The method of claim 20, wherein

The first negotiation response message further carries a protocol stack type priority set by the second negotiation device, so that the first negotiation device selects a protocol stack type priority preset according to the second negotiation device. And selecting, by the second negotiation device, the type of the protocol stack supported by the second negotiation device and the first negotiation device. .

22. The method of claim 19, wherein:

The negotiation request message further carries a protocol stack type priority set by the first negotiation device, and the method further includes: before the feeding back the first negotiation response message to the first negotiation device according to the negotiation request message,

Determining, according to the protocol stack type supported by the first negotiation device and the protocol stack type priority set by the first negotiation device, the second negotiation device and the first negotiation The type of protocol stack supported by the device;

The first negotiation response message carries a protocol stack type supported by the two parties selected by the second negotiation device.

The method according to claim 19, wherein the first negotiation response message carries a protocol stack type supported by the second negotiation device, so that the first negotiation device is configured according to the first negotiation. Selecting a protocol stack type supported by the second negotiation device and the first negotiation device by using the protocol stack type supported by the second negotiation device that is carried in the response message.

The method according to claim 23, wherein the first negotiation response message further carries a protocol stack type priority preset by the second negotiation device, so that the first negotiation device is configured according to the Determining, by the second negotiation device, the protocol stack type priority set by the second negotiation device and the protocol stack type supported by the second negotiation device, determining one of the second negotiation device and the first negotiation device The type of protocol stack that is commonly supported.

The method according to any one of claims 19 to 24, wherein the method further comprises:

And receiving, by the first negotiation device, a second negotiation response message, where the second negotiation response message carries a protocol stack type that is jointly supported by the first selected device by the first negotiation device.

The method according to any one of claims 19 to 25, wherein before the receiving, by the second negotiation device, the negotiation request message sent by the first negotiation device, the method further includes:

The key information is exchanged with the first negotiation device, so that the first negotiation device and the second negotiation device perform protocol stack type negotiation by using a public-private key encryption and decryption mechanism according to the key information.

The method according to any one of claims 19 to 25, further comprising:

Before receiving the negotiation request message sent by the first negotiation device, the second negotiation device shares a symmetric key with the first negotiation device;

Receiving, by the second negotiation device, the message ciphertext sent by the first negotiation device at the same time as the message is sent, decrypting the message ciphertext according to the symmetric key, obtaining a message plaintext, and clearing the message and receiving the message The obtained message is compared, and when the comparison result is the same, the protocol stack type negotiation is continued, where the message ciphertext is sent by the first negotiation device according to the symmetric key and the obtained random number pair to the first The message of the negotiating device is encrypted, and the obtained message ciphertext;

Before sending the message to the first negotiation device, the second negotiation device encrypts the message sent to the first negotiation device according to the symmetric key and the obtained random number, obtains the message ciphertext, and sends the message Sending the message ciphertext at the same time, so that the first negotiation device decrypts the received message ciphertext to obtain a message plaintext, and compares the message plaintext with the received message, when comparing the result When the same, continue the protocol stack type negotiation.

28. A protocol stack type negotiation device, wherein the device is configured to perform a protocol stack with a first negotiation device The second negotiation device of the type negotiation is characterized in that it includes:

a negotiation request message receiving unit, configured to receive a negotiation request message sent by the first negotiation device, where the negotiation request message carries a protocol stack type supported by the first negotiation device;

a protocol stack type obtaining unit, configured to select the second negotiation device to negotiate with the first negotiation device according to a protocol stack type supported by the first negotiation device that is carried in the negotiation request message received by the negotiation request message receiving unit The type of protocol stack supported by the device;

a first negotiation response message sending unit, configured to feed back a first negotiation response message to the first negotiation device according to the negotiation request message received by the negotiation request message receiving unit, so that the first negotiation device is configured according to the first Negotiating the response message, obtaining a protocol stack type supported by the second negotiation device and the first negotiation device.

The device according to claim 28, further comprising:

a protocol stack type determining unit, configured to determine at least one protocol stack type supported by the two parties; the first negotiation response message sent by the first negotiation response message sending unit carries the two parties determined by the protocol stack type determining unit At least one protocol stack type that is commonly supported, so that the first negotiation device selects, from the first negotiation response message, a protocol stack type supported by the second negotiation device and the first negotiation device.

30. Apparatus according to claim 29 wherein:

The first negotiation response message sent by the first negotiation response message sending unit further carries the protocol stack type priority set by the second negotiation device, so that the first negotiation device is configured according to the second negotiation device. Determining a protocol stack type priority, selecting at least one protocol stack type supported by the second negotiation device that is carried by the second negotiation device, and selecting one of the second negotiation device and the first A type of protocol stack that is commonly supported by the negotiation device.

31. Apparatus according to claim 28 wherein:

The negotiation request message received by the negotiation request message receiving unit further carries a protocol stack type priority preset by the first negotiation device;

The device also includes:

a selecting unit, configured to: before the first negotiation response message sending unit returns a first negotiation response message to the first negotiation device according to the negotiation request message received by the negotiation request message receiving unit, according to the negotiation request message The protocol stack type supported by the first negotiation device and the first Negotiating the protocol stack type priority set by the device, and selecting a protocol stack type supported by the second negotiation device and the first negotiation device;

The first negotiation response message carries a protocol stack type supported by the two selected by the selecting unit.

The apparatus according to claim 28, wherein the first negotiation response message sent by the first negotiation response message sending unit carries a protocol stack type supported by the second negotiation device, so that the The first negotiation device selects a protocol stack type supported by the second negotiation device and the first negotiation device according to the protocol stack type supported by the second negotiation device that is carried in the first negotiation response message.

The apparatus according to claim 32, wherein the first negotiation response message sent by the first negotiation response message sending unit further carries a protocol stack type priority preset by the second negotiation device, Determining, by the first negotiation device, a protocol stack type priority preset by the second negotiation device that is carried in the first negotiation response message, and a protocol stack type supported by the second negotiation device, The protocol stack type supported by the second negotiation device and the first negotiation device.

The device according to any one of claims 28 to 33, further comprising: a second negotiation response message receiving unit, configured to receive a second negotiation response message sent by the first negotiation device, where The second negotiation response message carries a protocol stack type jointly supported by the two selected by the first negotiation device.

35. Apparatus according to any one of claims 28 to 34, further comprising:

a key interaction unit, configured to exchange key information with the first negotiation device before the negotiation request message receiving unit receives the negotiation request message sent by the first negotiation device, so that the first negotiation device and the The second negotiating device performs protocol stack type negotiation by using a public-private key encryption and decryption mechanism according to the key information.

36. Apparatus according to any one of claims 28 to 34, further comprising:

a key sharing unit, configured to receive, by the negotiation request message receiving unit, the first negotiation device Sharing a symmetric key with the first negotiation device before negotiating the request message;

a decryption unit, configured to: after the second negotiation device receives the message ciphertext sent by the first negotiation device while sending the message, decrypt the message ciphertext according to the symmetric key shared by the key sharing unit And obtaining the message plaintext, where the message ciphertext is that the first negotiation device encrypts the message sent to the first negotiation device according to the symmetric key and the obtained random number, and the obtained message ciphertext ;

a comparing unit, configured to compare the plaintext of the message obtained by the decrypting unit with the received message, and continue to perform protocol stack type negotiation when the comparison result is the same;

An encryption unit, configured to send, by the second negotiation device, a message sent to the first negotiation device according to a symmetric key shared by the key sharing unit and a obtained random number pair before sending the message to the first negotiation device Encryption to obtain a message ciphertext;

a ciphertext sending unit, configured to send a message ciphertext obtained by the ciphering unit when the message is sent, so that the first negotiating device decrypts the received message ciphertext to obtain a message plaintext, The plaintext of the message is compared with the received message, and when the comparison result is the same, the protocol stack type negotiation is continued.