CN115694856A

CN115694856A - DHCP (dynamic host configuration protocol) -based authentication method and related equipment

Info

Publication number: CN115694856A
Application number: CN202110857898.4A
Authority: CN
Inventors: 徐亦斌; 郝卫国
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-07-28
Filing date: 2021-07-28
Publication date: 2023-02-03

Abstract

The embodiment of the application discloses a verification method based on a DHCP protocol and related equipment thereof, which are applied to the technical field of communication. The method comprises the following steps: the server receives a request message sent by the client, wherein the request message carries a client account and first verification information corresponding to the client. The first verification information is related to a client key corresponding to the client. The server inquires a client key corresponding to the client according to the client account carried by the request message, and then verifies the first verification information according to the client key corresponding to the inquired client. The embodiment of the application completes the validity verification between the DHCP client and the DHCP server in a key encryption mode, avoids the problem that the server is counterfeited or an illegal client attacks the server, improves the security of the DHCP protocol, and ensures the communication security.

Description

DHCP (dynamic host configuration protocol) -based authentication method and related equipment

Technical Field

The embodiment of the application relates to the technical field of communication, in particular to a verification method based on a DHCP protocol and related equipment.

Background

The Dynamic Host Configuration Protocol (DHCP) is a network protocol for a lan. Using a User Datagram Protocol (UDP) for communication, the DHCP server may automatically assign an IP address to a DHCP client that logs in to a TCP/IP network.

Generally, a DHCP client needs to send a request message to a DHCP server, and the DHCP server responds to the request message after receiving the DHCP request message, selects an IP address from an address pool and allocates the IP address to the DHCP client, and may also allocate other network parameters to the DHCP client. If the DHCP client and the DHCP server are in the same network segment, the DHCP client can send the request message by broadcasting. If not, DHCP relay is needed to forward DHCP message. Different from the conventional IP message forwarding, the DHCP relay usually modifies the message format again and generates a new DHCP message for forwarding after receiving the DHCP request message or the DHCP response message.

The existing DHCP standard does not have a definition of a user validity verification function. The security risk of the DHCP protocol is high, and if the validity verification is not performed, network problems such as server counterfeiting or server attack by an illegal client and the like are likely to occur. Therefore, how to perform the legal authentication between the DHCP client and the DHCP server becomes an urgent problem to be solved.

Disclosure of Invention

The embodiment of the application provides a verification method based on a DHCP protocol and related equipment. The validity verification between the DHCP client and the DHCP server is completed in a key encryption mode, the problem that the server is counterfeited or an illegal client attacks the server is avoided, the security of a DHCP protocol is improved, and the communication security is ensured.

A first aspect of an embodiment of the present application provides a verification method based on a DHCP protocol, including:

when a client needs to request an IP address from a server, a request message needs to be sent to the server, and the request message carries a client account corresponding to the client and first verification information. The first verification information is used for the server to verify the validity of the client and is related to the client key corresponding to the client. When the server receives the request message, the server needs to locally query a client key corresponding to the client account according to the client account in the request message, and verify the first verification information by using the queried client key.

In the above embodiment, when the client requests the server for the IP address through the request packet, the client needs to carry the client account and the first verification information, so that the server verifies the validity of the client account and responds to the successfully verified request packet. Therefore, the problem that the address of the server is exhausted due to the fact that the server is attacked by an illegal client can be avoided. Therefore, the problem of IP address resource waste is avoided, and the security of the DHCP protocol is improved.

In an alternative embodiment, before the client and the server perform DHCP communication, the server needs to assign a client account and a client key unique to each client through an outgoing mechanism. Meanwhile, the server needs to establish a corresponding relation table of the client account and the client key. Therefore, when the server receives the request message, the server can lock the client according to the client account carried in the request message, and inquire the client key corresponding to the client in the corresponding relation table. Therefore, the first verification information can be verified according to the inquired client-side secret key, whether the request message is legal or not is determined according to the verification result, and the illegal request message is responded. The corresponding relation table of the client account and the client key is established, the query efficiency of obtaining the client key can be improved, and the first verification information is verified through the queried client key, so that the validity verification efficiency can be improved.

In an optional implementation manner, when the server verifies that the first verification information is legal, the server needs to respond to the request message and send a response message to the client, so as to provide an IP address for the client, and complete the DHCP communication process. If the server obtains the request message illegally after the first verification information is verified, the server needs to discard the request message. Therefore, the server does not need to provide an IP address for the illegal request message, thereby avoiding the attack of the illegal client and avoiding the waste of IP address resources.

In an optional implementation manner, when the server sends the response message to the client, the response message also needs to carry second verification information, so that the client verifies whether the server is legal. The second authentication information is associated with the shared key when the server transmits the response packet in a unicast form, and is associated with a client key corresponding to the receiver client when the server transmits the response packet in a broadcast form.

In an optional implementation manner, the first authentication information may be a client key corresponding to the client and a hash value corresponding to the message field.

In an optional implementation manner, the second verification information may be a hash value corresponding to a client key and a packet field corresponding to the client, or a hash value corresponding to a shared key and a packet field.

A second aspect of the embodiments of the present application provides another verification method based on a DHCP protocol, including:

when a client applies for an IP address from a server, first verification information needs to be generated according to a client key so as to be used for the server to carry out validity verification. And then sending a request message to the server, wherein the request message carries a client account and first verification information corresponding to the client. Therefore, the server can verify the legality of the request message according to the first verification information and select to respond to the successfully verified request message. Therefore, the problem of IP address resource waste is avoided, and the security of the DHCP protocol is improved.

In an optional implementation manner, after responding to the request message sent by the client, the server sends a response message to the client. Meanwhile, the response message carries second verification information, and the second verification information is generated by the server according to the client key or the shared key. After receiving the response message, the client needs to verify the second verification information according to the client key or the shared key, and when the verification is legal, the client responds to the response message. When the verification is illegal, the client needs to discard the response message.

In the above embodiment, the client may verify the validity of the server according to the second verification information, so as to avoid the occurrence of server spoofing, thereby improving the security of DHCP communication.

In an optional implementation manner, the client may determine a hash value corresponding to the client key and the packet field as the first authentication information.

A third aspect of the embodiments of the present application provides another authentication method based on a DHCP protocol, including:

the server firstly obtains a public key corresponding to the client, and then receives a request message sent by the client. The request message is used for requesting the server to distribute an IP address for the client, and meanwhile, the request message carries a client certificate and a first private key signature field obtained according to a client private key. When the server receives the request message, identity verification is carried out according to a client certificate carried in the request message, if the identity verification is passed, the first private key signature field is decrypted according to a public key corresponding to the client, and a decryption result is verified.

In the above embodiment, when the client requests the server for the IP address through the request packet, the client needs to carry the client certificate and the first private key signature field, so that the server verifies the validity of the client and responds to the successfully verified request packet. Therefore, the problem that the address of the server is exhausted due to the fact that an illegal client side attacks the server can be avoided. Therefore, the problem of IP address resource waste is avoided, and the security of the DHCP protocol is improved.

In an optional implementation manner, after the server verifies the request packet, when the verification result is successful, the server needs to respond to the request packet and send a response packet to the client. Meanwhile, the response message comprises a second private key signature field obtained by the server private key. If the obtained result is that the verification fails, the server needs to discard the request message. Therefore, the server does not need to provide an IP address for the illegal request message, so that the attack of an illegal client is avoided, and the waste of IP address resources is avoided.

A fourth aspect of the embodiments of the present application provides another authentication method based on a DHCP protocol, including:

the client side firstly obtains a public key corresponding to the server and a server certificate corresponding to the server, and when the client side receives a response message sent by the server, the client side needs to verify the identity of the server according to the server certificate. After the identity authentication is successful, the client needs to decrypt the second private key signature field in the reply message according to the public key corresponding to the server, and verify the decryption result.

In an optional embodiment, if the verification is successful, the client needs to respond to a response message sent by the server. If the verification fails, the client needs to discard the response message.

A fifth aspect of embodiments of the present application provides a server, where the server includes:

the receiving unit is used for receiving a request message sent by a client; the request message carries a client account corresponding to the client and first verification information, and the first verification information is related to a client key corresponding to the client.

And the determining unit is used for inquiring the client key corresponding to the client according to the client account carried by the request message.

And the verification unit is used for verifying the first verification information according to the client key corresponding to the inquired client.

In an optional embodiment, the server further comprises:

and the distribution unit is used for distributing the client account and the client key for at least one client.

The determining unit is further used for determining a corresponding relation table between the client account and the client key; the client account number corresponds to the client password one by one.

And the determining unit is specifically configured to query the client key corresponding to the client account in the corresponding relationship table according to the client account carried in the request message.

In an alternative embodiment, the server further comprises a processing unit. The processing unit is specifically used for responding to the request message and sending a response message to the client when the verification unit verifies that the first verification information is legal; and when the verification unit verifies that the first verification information is illegal, discarding the request message.

In an optional implementation manner, the response packet carries the second authentication information. The second authentication information is associated with the client key when the response message is sent by the processing unit in unicast. The second authentication information is associated with the shared key when the response message is transmitted by the processing unit in a broadcast form.

In an optional implementation manner, the first authentication information is a hash value corresponding to the client key and the message field.

In an optional implementation manner, the second verification information is a hash value corresponding to the client key and the message field; or the second verification information is the hash value corresponding to the shared key and the message field.

A sixth aspect of embodiments of the present application provides a client device, where the client device includes:

and the processing unit is used for generating first verification information according to the client key corresponding to the client.

A sending unit, configured to send a request packet to a server; the request message is used for requesting the server to distribute an IP address for the client; the request message carries a client account and first verification information corresponding to the client.

In an optional implementation, the client device further comprises:

the receiving unit is used for receiving a response message sent by the server; the response message corresponds to the request message, the response message carries second verification information, and the second verification information is related to the client key or the shared key.

And the verification unit is used for verifying the second verification information according to the client key or the shared key.

The processing unit is also used for responding to the response message when the verification unit verifies that the second verification information is legal; and when the verification unit verifies that the second verification information is illegal, discarding the response message.

In an optional implementation manner, the processing unit is specifically configured to determine a hash value corresponding to the client key and the packet field as the first verification information.

In an optional implementation manner, the second verification information is a hash value corresponding to the client key and the message field; or the second verification information is the shared key and the hash value corresponding to the message field.

A seventh aspect of an embodiment of the present application provides a server, where the server includes:

and the acquisition unit is used for acquiring the public key corresponding to the client.

The receiving unit is used for receiving a request message sent by a client; the request message carries a client certificate corresponding to the client and a first private key signature field corresponding to the client.

And the verification unit is used for verifying the identity of the client according to the client certificate.

And the verification unit is also used for decrypting the first private key signature field according to the public key corresponding to the client after the identity verification is passed, and verifying the decryption result.

In an alternative embodiment, the server further comprises a processing unit.

The processing unit is specifically used for responding to the request message and sending a response message to the client if the verification unit succeeds in verification, wherein the response message comprises a second private key signature field corresponding to the server; and if the verification unit fails to verify, discarding the request message.

An eighth aspect of the embodiments of the present application provides a client device, where the client device includes:

and the acquisition unit is used for acquiring the public key corresponding to the server and the server certificate corresponding to the server.

And the receiving unit is used for receiving a response message sent by the server, wherein the response message comprises a second private key signature field corresponding to the server.

And the verification unit is used for verifying the identity of the server according to the server certificate.

And the verification unit is also used for decrypting the second private key signature field according to the public key corresponding to the server after the identity verification is passed, and verifying the decryption result.

In an optional implementation manner, the client device further includes a processing unit, where the processing unit is configured to respond to a response message sent by the server if the verification unit succeeds in verification; and if the verification unit fails to verify, discarding the response message.

A ninth aspect of the present application provides a server comprising: at least one processor, a memory, the memory storing computer-executable instructions executable on the processor, the processor performing the method according to any one of the possible implementations of the first aspect to the first aspect when the computer-executable instructions are executed by the processor.

A tenth aspect of the present application provides a client apparatus comprising: at least one processor, a memory, the memory storing computer-executable instructions executable on the processor, the processor performing the method according to any one of the possible implementations of the second aspect as described above when the computer-executable instructions are executed by the processor.

An eleventh aspect of the present application provides a server comprising: at least one processor, a memory, the memory storing computer-executable instructions operable on the processor, the processor performing the method according to any one of the possible implementations of the third aspect to the third aspect when the computer-executable instructions are executed by the processor.

A twelfth aspect of the present application provides a client device, comprising: at least one processor, a memory, the memory storing computer-executable instructions executable on the processor, the processor performing the method according to any one of the possible implementations of the fourth aspect to the fourth aspect when the computer-executable instructions are executed by the processor.

A thirteenth aspect of the present application provides a computer storage medium for storing computer software instructions for the server or client device described above, including a program designed for execution by the server or client device.

The server may be as described in the foregoing fifth aspect or seventh aspect.

The client device may be as described in the preceding sixth or eighth aspect.

According to the technical scheme, the method has the following advantages:

in the above embodiment, when the client requests the server for the IP address through the request packet, the client needs to carry the client account and the first verification information, so that the server verifies the validity of the client account and responds to the successfully verified request packet. Therefore, the problem that the address of the server is exhausted due to the fact that an illegal client side attacks the server can be avoided. Therefore, the problem of IP address resource waste is avoided, and the security of the DHCP protocol is improved.

Drawings

Fig. 1 is a network structure diagram of a DHCP networking according to an embodiment of the present application;

fig. 2 is a schematic flowchart of an interaction process between a DHCP client and a DHCP server according to an embodiment of the present disclosure;

fig. 3 is a flowchart of an authentication method based on a DHCP protocol according to an embodiment of the present application;

fig. 4 is a flowchart of another authentication method based on a DHCP protocol according to an embodiment of the present application;

fig. 5 is a schematic flowchart of another authentication method based on a DHCP protocol according to an embodiment of the present application;

fig. 6 is a schematic flowchart of another authentication method based on a DHCP protocol according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a server according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a client device according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of another server provided in the embodiment of the present application;

fig. 10 is a schematic structural diagram of another client device according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of another server provided in the embodiment of the present application;

fig. 12 is a schematic structural diagram of another server according to an embodiment of the present application.

Detailed Description

The technical solutions in the present application will be described in detail below with reference to the drawings in the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all embodiments.

The terms "first," "second," "third," "fourth," and the like in the description and claims of this application and in the above-described drawings, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein. Moreover, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

DHCP is a network protocol for local area networks, meaning that a range of IP addresses is controlled by a server. When the client logs in the server, the network parameters such as the IP address and the subnet mask distributed by the server can be automatically acquired. In general, DHCP is applied to a large-scale local area network environment to centrally manage and allocate IP addresses, so that a host in the network environment can dynamically obtain various network addresses to improve the utilization rate of the addresses.

Fig. 1 is a network structure diagram of a DHCP networking according to an embodiment of the present application, and as shown in fig. 1, a DHCP protocol uses a client/server model and includes a DHCP client, a DHCP server, and a DHCP relay. The DHCP client and the DHCP relay may be connected by a wired connection or an infinite connection, and are not particularly limited.

The DHCP server is responsible for selecting an IP address from the address pool and distributing the IP address to the DHCP client. Meanwhile, other network parameters such as a default gateway address, a DNS server address, a WINS server address and the like can be provided for the DHCP client. The DHCP server can receive and process the DHCP request message sent by the DHCP client side from the network segment, and can also receive and process the cross-network-segment DHCP request message forwarded by the DHCP relay.

The DHCP client is a device that sends a DHCP request message and requests to obtain network parameters such as an IP address through a DHCP protocol. Specifically, the DHCP client may be an IP phone, a mobile phone, a diskless workstation, etc.

The DHCP relay is a device responsible for forwarding a DHCP message between the DHCP server and the DHCP client and assisting the DHCP server to dynamically allocate network parameters to the DHCP client. It can be understood that the DHCP client may broadcast the request message in a unicast manner, or in a broadcast manner. If the DHCP client broadcasts a request message (i.e., the destination IP address is 255.255.255.255), the DHCP server located in the same network segment can receive the request message. However, if the DHCP client and the DHCP server are not in the same network segment, the DHCP server cannot receive the request message (broadcast) from the client. At this time, the DHCP request message and the response message sent by the subsequent DHCP server need to be forwarded through the DHCP relay. Different from the traditional IP message forwarding, after receiving the DHCP request message or the DHCP response message, the DHCP relay can revise the message format again, generate a new message and then forward the new message.

Specifically, after receiving a request message for applying for an address by a DHCP client in a network, the DHCP server sends a message such as a relevant address configuration to the DHCP client, so as to implement dynamic configuration of address information of the DHCP client. DHCP has the following functions:

1. the DHCP protocol can ensure that any IP address can only be used by one DHCP client at a time.

2. The DHCP protocol should be able to assign a permanent fixed IP address to the DHCP client.

3. The DHCP protocol should be compatible with hosts that obtain IP addresses in other ways (e.g., hosts that manually configure IP addresses).

4. The DHCP server should provide services to existing BOOTP clients.

The DHCP protocol has three mechanisms for allocating IP addresses, including:

the automatic allocation mode is that the DHCP server establishes a permanent IP address for the DHCP client, and once the DHCP client is successfully leased to the IP address from the DHCP server for the first time, the address can be permanently used.

The dynamic allocation mode is that when the DHCP server establishes an IP address with time limitation for the DHCP client, and the time expires or the DHCP client explicitly indicates to abandon the address, the address can be used by other DHCP clients, and this mode is also the only allocation mode that can reuse the address no longer needed by the client.

The manual allocation mode is that the IP address of the client is set by a network administrator, and the DHCP server only informs the set IP address to the client.

The following describes the interaction procedure between the DHCP client and the DHCP server in detail:

fig. 2 is a schematic flowchart of an interaction process between a DHCP client and a DHCP server according to an embodiment of the present disclosure. As shown in fig. 2, first, when the DHCP client needs to request an IP address, a DHCP discovery message, that is, a DHCP Discover message, may be sent in a broadcast manner. The purpose of the Discover message is to seek a DHCP server that can provide it with an IP address.

Then, the DHCP server that receives the Discover message will respond to the Discover message and send a DHCP Offer message, i.e., a DHCP Offer message, to the DHCP client. The DHCP Offer message is intended to tell the DHCP client that it can provide an IP address. And when the DHCP Offer message is sent, the DHCP server speaks the IP address carried in the DHCP Offer message. And simultaneously, after sending the message, the DHCP server adds a record of the allocated IP address.

The DHCP client may receive multiple DHCP Offer messages but it can only process one of them. A general processing principle is that a DHCP client processes a DHCP Offer message received first, and then sends a DHCP Request message, i.e., a DHCP Request message, based on the message, where the message carries an IP address of a DHCP server selected by the DHCP client.

And after receiving the DHCP Request message, the selected DHCP server judges whether the IP address of the field corresponding to the DHCP Request message is the same as the address of the selected DHCP server. If not, the DHCP server does not do any treatment, and only clears the corresponding IP address allocation record. If the two fields are the same, the DHCP server needs to send a feedback message, namely a DHCP ACK message, to the DHCP client, and adds the IP address and the use lease information of the IP address in the corresponding field.

And finally, after receiving the DHCP ACK message, the DHCP client judges whether the IP address indicated by the corresponding field can be used or not. If available, the DHCP client successfully obtains the IP address. If the DHCP client cannot use the IP address (the allocated IP address is occupied by other clients), the DHCP client can also send a DHCP Decline message to the DHCP server to inform the DHCP server to disable the IP address, and then the DHCP client enters a new round of address application process.

In the existing DHCP standard, the definition of a user validity verification function is not provided, and the security risk of a DHCP protocol is extremely high. The problem of server counterfeiting or the problem of server address exhaustion caused by malicious server attack by illegal clients can easily occur. To improve DHCP network security, existing techniques typically utilize a token mechanism to implement message authentication. That is, the sender inserts the configuration token into the DHCP information, the receiver compares the token in the information with the shared token, if the matching is successful, the information is processed, and if the matching is unsuccessful, the information is discarded. However, this method cannot be used in the address application stage, and requires authentication to be completed before address application. Meanwhile, when the client sends a failure, the server needs to update the configuration according to the new physical information of the client, which results in the low verification efficiency. Therefore, it is an urgent problem to complete the authentication between the DHCP client and the DHCP server more efficiently and accurately.

Fig. 3 is a flowchart of an authentication method based on a DHCP protocol according to an embodiment of the present application. As shown in fig. 3, the method includes the following steps.

301. The server allocates a client account and a client key to at least one client.

In order to improve the security of the DHCP protocol, a key mechanism may be used to verify the validity of the message, so that both the DHCP server and the DHCP client only respond to the valid message and discard the invalid message. First, the DHCP server needs to distribute accounts and keys for DHCP clients. Namely, each DHCP client of the DHCP server to be logged corresponds to one account and one key. The account, the key and the client are in one-to-one correspondence, the account corresponding to each DHCP client is different, and the key is different. Therefore, the DHCP server can distinguish different DHCP clients according to the account and the key, and can verify the legality of the DHCP clients.

When the DHCP server distributes the account and the key to the DHCP client, the DHCP server may establish a correspondence table between the account and the key according to the distribution condition, and store the correspondence table to perform a subsequent verification process.

302. And the server receives a request message sent by the client.

When the DHCP client sends a request message to the DHCP server to request an IP address, the DHCP server does not need to verify the legality of the DHCP client in advance, but directly receives the request message sent by the DHCP client in an address request stage. The request message carries a client account of the DHCP client and first authentication information. The first authentication information is related to the client key, and may be, for example, a hash value corresponding to the client key and the message field. Therefore, other illegal servers can be prevented from stealing the request message and acquiring the key corresponding to the DHCP client. The DHCP server can verify the validity of the DHCP client according to the client account and the first verification information carried in the request message.

303. And the server queries a client key corresponding to the client according to the client account carried in the request message.

Specifically, because the client key corresponding to the DHCP client is distributed by the DHCP server, the DHCP server may find the client key corresponding to the client account in the correspondence table between the client account and the client key, where the found client key is the client key corresponding to the DHCP client.

304. And the server verifies the first verification information in the request message according to the client key. If the verification is successful, step 305 is performed, and if the verification is failed, step 306 is performed.

When the DHCP server acquires the client key corresponding to the DHCP client by using the corresponding relation table, the DHCP server can verify the first verification information according to the key. For example, the DHCP server may use the same hash algorithm to calculate the found client key and the related packet field, and compare the calculation result with the first verification information. If the two verification information are the same, the client account and the first verification information carried in the request message are legal, and the DHCP server needs to respond to the request message. If the request message is different from the client-side account, the client-side account and the first authentication information carried in the request message are not legal, and the DHCP server cannot allocate the IP address based on the request message.

305. And the server sends a response message to the client.

Specifically, the DHCP server calculates the found client key and the relevant message field by using the same hash algorithm, and compares the calculation result with the first verification information. If the two verification messages are the same, the client account and the first verification information carried in the request message are legal, and the DHCP server responds to the request message and sends a response message to the DHCP client so as to allocate an IP address for the DHCP client.

It can be understood that, when the server sends the response message, the second verification information needs to be carried in the response message. The second verification information may be a hash value corresponding to a client key and a packet field corresponding to the DHCP client, or may be a hash value corresponding to a shared key and a packet field. The second authentication information is authentication information for the DHCP client to authenticate the validity of the DHCP server. Only if the client verifies the legality of the server, the DHCP server can be prevented from being tampered or counterfeited.

306. The server discards the request message.

If the verification result of the DHCP server is that the client account and the first verification information carried in the request message are not legal, the DHCP server needs to discard the request message. Therefore, when the illegal client sends a request message to the DHCP server, the DHCP server can know that the sender is the illegal client according to the information in the request message, and the DHCP server does not respond to the illegal message, so that the phenomenon that the illegal client maliciously attacks the DHCP server to exhaust the IP address owned by the DHCP server can be avoided. The security of the DHCP protocol is greatly improved.

In the above embodiment, the DHCP server allocates the client account and the client key to the DHCP client, so that when the client sends the request message, the client may generate the first verification information according to the client key, and carry the client account and the client key in the request message to send to the DHCP server. The DHCP server can inquire the corresponding client-side secret key according to the client-side account carried in the message, calculate the inquired client-side secret key, compare and verify the calculation result with the first verification information, respond to the request message if the verification is successful, and discard the request message if the verification is failed. Therefore, the server can avoid processing illegal messages, and prevent the phenomenon that an illegal client maliciously attacks the DHCP server to exhaust the IP address owned by the DHCP server. The security of the DHCP protocol is greatly improved.

Fig. 4 is a flowchart of another authentication method based on a DHCP protocol according to an embodiment of the present application. As shown in fig. 3, the method includes the following steps.

401. The client obtains a client account and a client key.

It is understood that step 401 corresponds to step 301 shown in the embodiment of fig. 3. The DHCP server distributes accounts and keys for DHCP clients. Namely, each DHCP client of the DHCP server to be logged in corresponds to one account and one key. The account, the key and the client are in one-to-one correspondence, the account corresponding to each DHCP client is different, and the key is different. Therefore, the DHCP server can distinguish different DHCP clients conveniently according to the account and the key, and can verify the legality of the DHCP clients. The client needs to generate authentication information according to the corresponding client account and the client key to prove the identity of the client.

402. The client generates first verification information according to the client key.

Before the DHCP client sends a request message to the DHCP server to request an IP address, the DHCP client needs to generate first authentication information according to a client key, so as to serve as information of self identity. For example, the client may calculate the client key and the packet field to obtain a hash value corresponding to the client key and the packet field, and determine the hash value as the first verification information. The first verification information is the identity verification information of the DHCP client, and is used for verifying the validity of the DHCP client by the DHCP server.

403. The client sends a request message to the server.

When the DHCP client side sends a request message to the DHCP server to request an IP address, the DHCP server does not need to verify the validity of the DHCP client side in advance, but directly receives the request message sent by the DHCP client side in an address request stage. The request message carries the client account of the DHCP client and the first authentication information.

404. And the client receives a response message corresponding to the request message.

After the DHCP server verifies the validity of the DHCP client according to the first verification information, if the DHCP client is determined to be legal, the DHCP server needs to respond to the request message and send a response message to the client, wherein the response message can carry an IP address distributed to the client. Meanwhile, the response message also needs to carry second verification information to allow the client to verify the legitimacy of the server, so as to avoid server counterfeiting.

405. And the client verifies the second verification information in the response message. If the verification is legal, go to step 406. If the verification is illegal, go to step 407.

Specifically, after receiving the response message, the DHCP client obtains second verification information included in the response message, where the second verification information may be a hash value corresponding to the shared key and the message field, or may also be a hash value corresponding to the client key and the message field corresponding to the DHCP client. When the DHCP server sends the response message in a broadcast mode, the second verification information is the hash value corresponding to the shared key and the message field, and when the DHCP server sends the response message in a unicast mode, the second verification information is the hash value corresponding to the client key and the message field.

The DHCP client can utilize the same hash algorithm to perform hash calculation on the shared key or the client key and the related message field, then the obtained hash result is compared with the second verification information, if the hash result is the same as the second verification information, the verification is successful, and if the hash result is different from the second verification information, the verification fails.

406. The client acquires the IP address in the response message.

If the DHCP client side is successfully verified, the IP address carried in the response message can be obtained, and other network communication activities are carried out by utilizing the IP address.

407. The client discards the response message.

If the DHCP client fails in verification, the response message needs to be discarded, so that the server is prevented from being sent by a network problem falsely used, and the security of a DHCP protocol is improved.

In the above embodiment, when receiving the response packet sent by the DHCP server, the DHCP client verifies the second verification information carried in the response packet according to the client key or the shared key, specifically, the client key or the shared key may be subjected to hash calculation by using the same hash algorithm as that of the DHCP server, and the calculation result is compared with the second verification information for verification, if the verification is successful, the IP address carried in the response packet is used, and if the verification fails, the response packet is discarded. Therefore, the client can avoid using the IP address in the illegal message and prevent the illegal server from counterfeiting. The security of the DHCP protocol is greatly improved.

The authentication method based on the DHCP protocol is described in detail below based on a specific application scenario. Fig. 5 is a flowchart of another authentication method based on a DHCP protocol according to an embodiment of the present application, including:

501. and the server sends the client account and the client password to the client in an outgoing mode.

It can be understood that step 501 is similar to step 301 in the embodiment shown in fig. 3, and is not repeated herein.

502. The client configures the home terminal according to the client account and the client password, and generates first verification information according to the client password.

Before the client requests the IP address, the client needs to generate first verification information according to a client key to serve as the information of the self identity certificate. For example, the client may calculate the client key and the packet field to obtain a hash value corresponding to the client key and the packet field, and determine the hash value as the first verification information. The first verification information is identity verification information of the DHCP client, and is used for verifying the validity of the DHCP client by the server.

503. The client sends a DHCP discovery message (DHCP Discover message) in a broadcast manner.

When a client needs to request an IP address, a DHCP discovery message, that is, a DHCP Discover message, may be sent in a broadcast manner first. The purpose of the DHCP Discover message is to seek a DHCP server that can provide it with an IP address. Specifically, when the client sends the DHCP Discover message, the client account and the first verification information corresponding to the client are required to be carried in the DHCP Discover message.

504. And the server queries a client key corresponding to the client according to the client account carried in the request message.

Specifically, because the client key corresponding to the client is distributed by the server, the server may find the client key corresponding to the client account in the correspondence table between the client account and the client key, where the found client key is the client key corresponding to the client.

505. And the server verifies the first verification information in the request message according to the client key. If the verification is successful, go to step 506, and if the verification fails, go to step 507.

And when the server acquires the client key corresponding to the client by using the corresponding relation table, the server can verify the first verification information according to the key. For example, the server may calculate the found client key and the found relevant packet field by using the same hash algorithm, and compare the calculation result with the first verification information. If the first authentication information is the same as the second authentication information, the server needs to respond to the request message, which indicates that the client account and the first authentication information carried in the request message are legal. If the request message is different from the first verification message, the client account and the first verification information carried in the request message are illegal, and the server cannot allocate the IP address based on the request message.

506. The server responds to the DHCP Discover message and sends a DHCP Offer message (DHCP Offer message) to the client.

Wherein the DHCP Offer message is intended to tell the client that it can provide an IP address. And when the server is in the DHCP Offer message, the server speaks that the IP address of the server is carried in the DHCP Offer message. And simultaneously, after sending the message, the DHCP server adds a record of the allocated IP address.

Meanwhile, the server needs to carry second verification information in the DHCP Offer message for the client to verify the legitimacy of the server.

507. The server discards the request message.

It is understood that step 507 is similar to step 306 in the embodiment shown in fig. 3, and is not repeated herein.

508. And the client verifies the second verification information in the DHCP Offer message. If the verification is legal, go to step 509.

Specifically, after receiving the response message, the DHCP client acquires second verification information included in the response message, where the second verification information may be a hash value corresponding to the shared key and the message field, or may be a hash value corresponding to the client key and the message field corresponding to the DHCP client. Specifically, the second verification information carried in the response message is a hash value corresponding to a client key and a message field when the server sends the response message in a unicast mode, and the second verification information carried in the response message is a hash value corresponding to a shared key and a message field when the server sends the response message in a broadcast mode.

The DHCP client can utilize the same hash algorithm to perform hash calculation on the shared key or the client key and the related message field, then compare the obtained hash result with the second verification information, if the hash result is the same as the second verification information, the verification is successful, and if the hash result is different from the second verification information, the verification fails. It can be understood that, if the verification fails, the client needs to discard the DHCP Offer message.

509. The client sends a DHCP Request message (DHCP Request message) to the server.

It can be understood that the DHCP Request packet also carries the client account and the first verification information, so that the server performs validity verification again.

510. And the server verifies the DHCP Request message.

The process of verifying the DHCP Request message by the server is similar to the process of verifying the DHCP Offer message by the server, and for the specific verification process, reference is made to steps 504 to 507, which is not described herein again.

511. And the server sends a DHCP feedback message (DHCP ACK message) to the client.

And the client side carries the IP address and lease information corresponding to the IP address according to the DHCP ACK message. An IP address is obtained.

According to the embodiment of the application, the security verification between the server and the client is completed by utilizing a password mechanism, the problem that the server is counterfeited or an illegal client attacks the server is avoided, the security of a DHCP protocol is improved, and the communication security is ensured.

It is to be understood that a public key mechanism may also be used to verify the validity between the DHCP client and the DHCP server, and another verification method is described in detail below based on a specific application scenario. Fig. 6 is a flowchart of another authentication method based on a DHCP protocol according to an embodiment of the present application, where the method includes:

601. the client obtains a client certificate and a server certificate.

Specifically, the client may obtain a certificate corresponding to the client and a server certificate from a Certificate Authority (CA) to provide the server with the authentication information. And meanwhile, the server certificate is also utilized to carry out identity verification on the server.

602. The client sends a DHCP discovery message (DHCP Discover message) in a broadcast form.

When a client needs to request an IP address, a DHCP discovery message, that is, a DHCP Discover message, may be sent in a broadcast manner first. The purpose of this DHCP Discover message is to seek a DHCP server that can provide it with an IP address. Specifically, when the client sends the DHCP Discover message, the client certificate and the first private key signature field corresponding to the client are required to be carried in the DHCP Discover message.

The signature field means that the client encrypts some fields in the message by using a private key to provide verification information for the server.

603. And the server performs identity authentication on the client according to the client certificate in the DHCP Discover message. If the verification fails, step 604 is performed, and if the verification succeeds, step 605 is performed.

604. The server discards the DHCP Discover message.

It can be understood that, if the client certificate is illegal, the client sending the DHCP Discover message is proved to be illegal. The server does not need to respond to the DHCP Discover message, and the problem that the address corresponding to the server is exhausted due to the fact that an illegal client side attacks the server is avoided.

605. And the server verifies the first private key signature field by using the public key corresponding to the client.

Specifically, the server may decrypt the first private key signature field by using the public key, and verify the decryption result, if the verification is successful, step 606 is executed, and if the verification fails, step 604 is executed again.

606. The server sends a DHCP Discover message to the client in response to the server, and sends a DHCP Offer message (DHCP Offer message) to the client.

Wherein the DHCP Offer message is intended to tell the client that it can provide an IP address. And when the server is in the DHCP Offer message, the server speaks the IP address of the server to be carried in the DHCP Offer message. And simultaneously, after sending the message, the DHCP server adds a record of the allocated IP address.

Meanwhile, the server needs to carry a second private key signature field in the DHCP Offer message according to the private key corresponding to the server. That is, the server needs to encrypt the corresponding fields of the DHCP Offer message according to the private key corresponding to the server.

607. And the client performs identity verification on the server according to the server certificate. If the verification fails, go to step 608, and if the verification succeeds, go to step 609.

608. The client discards the DHCP Offer message.

It will be appreciated that if the client verifies that the server is illegitimate based on the server certificate, the server may assume that the server is counterfeit and need not request an IP address from the server.

609. And the client verifies the second private key signature field by using the public key corresponding to the server.

Specifically, the client may decrypt the second private key signature field by using the public key corresponding to the server, and verify the decryption result, if the verification is successful, execute step 610, and if the verification fails, execute step 608 again.

610. The client sends a DHCP Request message (DHCP Request message) to the server.

It can be understood that the DHCP Request message also carries the client certificate and the first private key signature field, so that the server performs validity verification again.

611. And the server verifies the DHCP Request message.

The process of verifying the DHCP Request message by the server is similar to the process of verifying the DHCP Offer message by the server, and for the verification process, reference is made to steps 603 to 606, which are not described herein again.

612. The server sends a DHCP feedback message (DHCP ACK message) to the client.

According to the embodiment of the application, the public key mechanism is utilized to complete the security verification between the server and the client, so that the problem that the server is counterfeited or an illegal client attacks the server is avoided, the security of the DHCP protocol is improved, and the communication security is ensured.

Fig. 7 is a schematic structural diagram of a server according to an embodiment of the present application, and as shown in fig. 7, the server includes:

a receiving unit 701, configured to receive a request packet sent by a client; the request message carries a client account corresponding to the client and first verification information, and the first verification information is related to a client key corresponding to the client.

The determining unit 702 is configured to query, according to the client account carried in the request packet, a client key corresponding to the client.

The verifying unit 703 is configured to verify the first verification information according to the client key corresponding to the queried client.

In an optional embodiment, the server further comprises:

an assigning unit 704 is configured to assign a client account and a client key to at least one client.

A determining unit 702, configured to determine a correspondence table between a client account and a client key; the client account number corresponds to the client password one by one.

The determining unit 702 is specifically configured to query, according to the client account carried in the request message, the client key corresponding to the client account in the correspondence table.

In an alternative embodiment, the server further comprises a processing unit 705. The processing unit 705 is specifically configured to, when the verification unit verifies that the first verification information is valid, respond to the request message and send a response message to the client; and when the verification unit verifies that the first verification information is illegal, discarding the request message.

In an optional implementation manner, the response packet carries the second authentication information. When the response message is sent by the processing unit 705 in unicast, the second authentication information is associated with the client key. When the response message is sent by the processing unit 705 in a broadcast form, the second authentication information is associated with the shared key.

Fig. 8 is a schematic structural diagram of a client device according to an embodiment of the present application, and as shown in fig. 8, the client device includes:

the processing unit 801 is configured to generate first authentication information according to a client key corresponding to the client.

A sending unit 802, configured to send a request message to a server; the request message is used for requesting the server to distribute an IP address for the client; the request message carries a client account corresponding to the client and first verification information.

In an optional implementation, the client device further comprises:

a receiving unit 803, configured to receive a response message sent by a server; the response message corresponds to the request message, the response message carries second verification information, and the second verification information is related to the client key or the shared key.

The verifying unit 804 is configured to verify the second verification information according to the client key or the shared key.

The processing unit 801 is further configured to respond to the response message when the verifying unit verifies that the second verification information is legal; and when the verification unit verifies that the second verification information is illegal, discarding the response message.

In an optional implementation manner, the processing unit 801 is specifically configured to determine a hash value corresponding to the client key and the packet field as the first authentication information.

Fig. 9 is a schematic structural diagram of another server provided in the embodiment of the present application, and as shown in fig. 9, the server includes:

an obtaining unit 901, configured to obtain a public key corresponding to the client.

A receiving unit 902, configured to receive a request packet sent by a client; the request message carries a client certificate corresponding to the client and a first private key signature field corresponding to the client.

And the verifying unit 903 is configured to perform identity verification on the client according to the client certificate.

The verifying unit 903 is further configured to decrypt the first private key signature field according to the public key corresponding to the client after the identity verification passes, and verify a decryption result.

In an alternative embodiment, the server further comprises a processing unit 904.

The processing unit 904 is specifically configured to, if the verification unit 903 verifies successfully, respond to the request message and send a response message to the client, where the response message includes a second private key signature field corresponding to the server; if the verification unit 903 fails in the verification, the request message is discarded.

Fig. 10 is a schematic structural diagram of another client device according to an embodiment of the present application, and as shown in fig. 10, the client device includes:

an obtaining unit 1001 is configured to obtain a public key corresponding to a server and a server certificate corresponding to the server.

The receiving unit 1002 is configured to receive a response message sent by the server, where the response message includes a second private key signature field corresponding to the server.

An authentication unit 1003, configured to authenticate the server according to the server certificate.

The verifying unit 1003 is further configured to decrypt the second private key signature field according to the public key corresponding to the server after the identity verification passes, and verify a decryption result.

In an optional implementation manner, the client device further includes a processing unit 1004, and the processing unit 1004 is configured to respond to the response message sent by the server if the verification by the verification unit is successful, and discard the response message sent by the server if the verification by the verification unit fails.

Referring to fig. 11, which is a schematic structural diagram of another server provided in an embodiment of the present application, the server 1100 includes: processor 1101, memory 1102, communication interface 1103.

The processor 1101, the memory 1102, and the communication interface 1103 are connected to each other by a bus; the bus may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 11, but this is not intended to represent only one bus or type of bus.

Memory 1102 may include volatile memory (volatile memory), such as random-access memory (RAM); the memory may also include a non-volatile memory (non-volatile memory), such as a flash memory (flash memory), a Hard Disk Drive (HDD) or a solid-state drive (SSD); the memory 1102 may also comprise a combination of the above types of memory.

The processor 1101 may be a Central Processing Unit (CPU), a Network Processor (NP), or a combination of a CPU and an NP. The processor 1101 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof.

The communication interface 1103 may be a wired communication interface, such as an ethernet interface, a wireless communication interface, or a combination thereof. The ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a WLAN interface, a cellular network communication interface, a combination thereof, or the like.

Optionally, the memory 1102 may also be configured to store program instructions, and the processor 1101 calls the program instructions stored in the memory 1102, and may perform one or more steps in any one of the method embodiments shown in fig. 3 to fig. 6, or an optional implementation thereof, so that the server 1100 implements the functions of the server in the foregoing method, which is not described herein again.

Referring to fig. 12, a schematic structural diagram of another client device according to an embodiment of the present application is shown, where the client device 1200 includes: a processor 1201, a memory 1202, and a communication interface 1203.

The processor 1201, the memory 1202, and the communication interface 1203 are connected to each other by a bus; the bus may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 12, but this is not intended to represent only one bus or type of bus.

Memory 1202 may include volatile memory (volatile memory), such as random-access memory (RAM); the memory may also include a non-volatile memory (non-volatile memory), such as a flash memory (flash memory), a hard disk (HDD) or a solid-state drive (SSD); memory 1202 may also comprise a combination of the above types of memory.

The processor 1201 may be a Central Processing Unit (CPU), a Network Processor (NP), or a combination of a CPU and an NP. The processor 1201 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof.

The communication interface 1203 may be a wired communication interface, such as an ethernet interface, a wireless communication interface, or a combination thereof. The ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a WLAN interface, a cellular network communication interface, a combination thereof, or the like.

Optionally, the memory 1202 may also be used for storing program instructions, and the processor 1201 invokes the program instructions stored in the memory 1202, and may perform one or more steps in any one of the method embodiments shown in fig. 3 to fig. 6, or an optional implementation thereof, so that the client device 1200 implements the functions of the client in the method, which is not described herein again.

The embodiment of the present application further provides a chip or a chip system, where the chip or the chip system includes at least one processor and a communication interface, the communication interface and the at least one processor are interconnected by a line, and the at least one processor executes instructions or a computer program to perform one or more steps in the method embodiments shown in fig. 3 to fig. 6, or an alternative implementation manner thereof, so as to implement the functions of the server in the method.

The communication interface in the chip may be an input/output interface, a pin, a circuit, or the like.

In a possible implementation, the chip or chip system described above further comprises at least one memory, in which instructions are stored. The memory may be a storage unit inside the chip, such as a register, a cache, etc., or may be a storage unit of the chip (e.g., a read-only memory, a random access memory, etc.).

The embodiment of the present application further provides a chip or a chip system, where the chip or the chip system includes at least one processor and a communication interface, the communication interface and the at least one processor are interconnected by a line, and the at least one processor is configured to execute a computer program or instructions to perform the method for executing the client described in any one of any possible implementation manners of the embodiments shown in fig. 3 to fig. 6;

In one possible implementation, the chip or chip system described above in this application further comprises at least one memory having instructions stored therein. The memory may be a storage unit inside the chip, such as a register, a cache, etc., or may be a storage unit of the chip (e.g., a read-only memory, a random access memory, etc.).

Embodiments of the present application further provide a computer storage medium, which is used to store computer software instructions for the server or the client, and includes a program designed to execute the server or the client.

The server may be as described in the foregoing fig. 7 or fig. 9.

The detection unit may be a client device as described in the foregoing fig. 8 or fig. 10.

An embodiment of the present application further provides a computer program product, where the computer program product includes computer software instructions, and the computer software instructions may be loaded by a processor to implement the processes in the DHCP protocol-based authentication methods shown in fig. 3 to fig. 6.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product.

The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the present application are generated in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website, computer, server, or data center to another website, computer, server, or data center via wire (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can store or a data storage device, such as a server, a data center, etc., that is integrated with one or more available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), among others.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in the form of hardware, or may also be implemented in the form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application may be embodied in the form of software products, in essence or as a part of the contribution to the art, or all or part of the technical solutions.

Claims

1. An authentication method based on DHCP protocol, the method comprising:

a server receives a request message sent by a client; the request message carries a client account corresponding to the client and first verification information, and the first verification information is related to a client key corresponding to the client;

the server inquires a client key corresponding to the client according to the client account carried by the request message;

and the server verifies the first verification information according to the inquired client key corresponding to the client.

2. The method according to claim 1, wherein before the server receives the request message sent by the client, the method further comprises:

the server distributes a client account and a client key for at least one client, and determines a corresponding relation table between the client account and the client key; the client account and the client password are in one-to-one correspondence;

the server queries a client key corresponding to the client according to the client account carried in the request message, and the server comprises:

and the server inquires the client key corresponding to the client account in the corresponding relation table according to the client account carried by the request message.

3. The method according to any one of claims 1 to 2, further comprising:

when the server verifies that the first verification information is legal, the server responds to the request message and sends a response message to the client;

and when the server verifies that the first verification information is illegal, the server discards the request message.

4. The method according to claim 3, wherein the response packet carries second authentication information;

when the response message is sent by the server in a unicast mode, the second verification information is related to the client key;

when the response message is sent by the server in a broadcast form, the second authentication information is associated with a shared key.

5. The method according to any one of claims 1 to 4, wherein the first authentication information is a hash value corresponding to the client key and the packet field.

6. The method according to any one of claims 1 to 5, wherein the second authentication information is a hash value corresponding to a client key and a message field; or

And the second verification information is the hash value corresponding to the shared key and the message field.

7. An authentication method based on a DHCP protocol, the method comprising:

the client generates first verification information according to a client key corresponding to the client;

the client sends a request message to a server; the request message is used for requesting the server to distribute an IP address for the client; the request message carries a client account and first verification information corresponding to the client.

8. The method of claim 7, further comprising:

the client receives a response message sent by the server; the response message corresponds to the request message, the response message carries second verification information, and the second verification information is related to the client key or the shared key;

the client verifies the second verification information according to the client key or the shared key;

when the client verifies that the second verification information is legal, the client responds to the response message;

and when the client verifies that the second verification information is illegal, the client discards the response message.

9. The method according to any one of claims 7 to 8, wherein the generating, by the client, the first authentication information according to the client key and the shared key corresponding to the client comprises:

and the client determines the hash value corresponding to the client key and the message field as the first verification information.

10. The method of any of claims 7 to 9, wherein the second authentication information is a hash value corresponding to a client key and a message field; or

And the second verification information is the hash value corresponding to the shared secret key and the message field.

11. A method for authenticating a DHCP protocol, the method comprising:

a server acquires a public key corresponding to a client;

the server receives a request message sent by the client; the request message carries a client certificate corresponding to the client and a first private key signature field corresponding to the client;

the server carries out identity verification on the client according to the client certificate;

and after the identity authentication is passed, the server decrypts the first private key signature field according to the public key corresponding to the client and verifies the decryption result.

12. The authentication method of claim 11, further comprising:

if the verification is successful, the server responds to the request message and sends a response message to the client; the response message comprises a second private key signature field corresponding to the server;

and if the verification fails, the server discards the request message.

13. A method for authenticating a DHCP protocol, the method comprising:

a client acquires a public key corresponding to a server and a server certificate corresponding to the server;

the client receives a response message sent by the server, wherein the response message comprises a second private key signature field corresponding to the server;

the client side carries out identity authentication on the server according to the server certificate;

and after the identity verification is passed, the server decrypts the second private key signature field according to the public key corresponding to the server, and verifies the decryption result.

14. The authentication method of claim 13, further comprising:

if the verification is successful, the client side responds to the response message sent by the server;

and if the verification fails, the client discards the response message sent by the server.

15. A server, characterized in that the server comprises:

the receiving unit is used for receiving a request message sent by a client; the request message carries a client account corresponding to the client and first verification information, and the first verification information is related to a client key corresponding to the client;

a determining unit, configured to query, according to the client account carried in the request packet, a client key corresponding to the client;

and the verification unit is used for verifying the first verification information according to the inquired client key corresponding to the client.

16. The server of claim 15, further comprising:

the distribution unit is used for distributing a client account and a client key for at least one client;

the determining unit is further configured to determine a correspondence table between the client account and the client key; the client account and the client password are in one-to-one correspondence;

the determining unit is specifically configured to query, according to the client account carried in the request packet, the client key corresponding to the client account in the correspondence table.

17. The server according to any one of claims 15 to 16, wherein the server further comprises a processing unit, the processing unit being specifically configured to send a response message to the client in response to the request message when the verifying unit verifies that the first verification information is legitimate; and when the verification unit verifies that the first verification information is illegal, discarding the request message.

18. The server according to claim 17, wherein the response packet carries second authentication information;

when the response message is sent by the processing unit in a unicast form, the second verification information is related to the client key; when the response message is sent by the processing unit in a broadcast form, the second authentication information is associated with a shared key.

19. The server according to any one of claims 15 to 18, wherein the first authentication information is a hash value corresponding to the client key and the packet field.

20. The server according to any one of claims 15 to 19, wherein the second authentication information is a hash value corresponding to a client key and a message field; or the second verification information is the hash value corresponding to the shared key and the message field.

21. A client device, the client device comprising:

the processing unit is used for generating first verification information according to a client key corresponding to the client;

22. The client device of claim 21, wherein the client device further comprises:

a receiving unit, configured to receive a response packet sent by the server; the response message corresponds to the request message, the response message carries second verification information, and the second verification information is related to the client key or the shared key;

the verification unit is used for verifying the second verification information according to the client key or the shared key;

the processing unit is further configured to respond to the response packet when the verifying unit verifies that the second verification information is legal; and when the verification unit verifies that the second verification information is illegal, discarding the response message.

23. The client device of any one of claims 21 to 22,

the processing unit is specifically configured to determine a hash value corresponding to the client key and the packet field as the first verification information.

24. The client device of any of claims 21 to 23, wherein the second authentication information is a hash value corresponding to a client key and a message field; or the second verification information is the hash value corresponding to the shared key and the message field.

25. A server, characterized in that the server comprises:

the acquisition unit is used for acquiring a public key corresponding to the client;

a receiving unit, configured to receive a request packet sent by the client; the request message carries a client certificate corresponding to the client and a first private key signature field corresponding to the client;

the verification unit is used for verifying the identity of the client according to the client certificate;

and the verification unit is further used for decrypting the first private key signature field according to the public key corresponding to the client after the identity verification is passed, and verifying a decryption result.

26. The server of claim 25, wherein the server further comprises a processing unit;

the processing unit is specifically configured to, if the verification unit succeeds in verification, respond to the request packet and send a response packet to the client, where the response packet includes a second private key signature field corresponding to the server; and if the verification unit fails to verify, discarding the request message.

27. A client device, the client device comprising:

the system comprises an acquisition unit, a verification unit and a verification unit, wherein the acquisition unit is used for acquiring a public key corresponding to a server and a server certificate corresponding to the server;

the receiving unit is used for receiving a response message sent by the server, and the response message comprises a second private key signature field corresponding to the server;

the authentication unit is used for authenticating the server according to the server certificate;

and the verification unit is further used for decrypting the second private key signature field according to the public key corresponding to the server after the identity verification is passed, and verifying the decryption result.

28. The client device of claim 27, further comprising a processing unit;

the processing unit is used for responding to the response message sent by the server if the verification unit successfully verifies the response message; and if the verification unit fails to verify, discarding the response message sent by the server.

29. A server, comprising: at least one processor and a communication interface, the server performing the method according to any one of the possible implementations of claims 1 to 6 or 11 to 12.

30. A client device, comprising: at least one processor, a memory storing computer-executable instructions executable on the processor, the processor performing the method as recited in any one of the possible implementations of claims 7 to 10 or 13 to 14 when the computer-executable instructions are executed by the processor.

31. A computer-readable storage medium storing one or more computer-executable instructions, wherein when the computer-executable instructions are executed by a processor, the processor performs the method of any one of claims 1 to 14.