Equipment authentication method and device

Abstract

The invention provides an equipment authentication method and device, and relates to the technical field of communication. The method comprises the steps that target verification information and a verification file corresponding to target equipment are acquired, the target verification information is used for indicating identification information of the target equipment, and the verification file is used for indicating initial identification information when the target equipment leaves a factory; and determining the legality of the target equipment based on the target verification information and the verification file. The method and the device are used for identifying conditions such as counterfeiting and goods fleeing of the target device so as to improve the accuracy of device authentication.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a device authentication method and apparatus. Background Technology

[0002] Currently, with the rapid development of communication technology, the types of communication equipment and the functions they support are becoming increasingly diversified, greatly enhancing the user experience. However, with the expansion of the market, the number of malicious manufacturers is also increasing, leading to a proliferation of problems such as counterfeit equipment and malicious cross-selling, seriously damaging the economic benefits of enterprises. Therefore, the accuracy of current equipment legality certification urgently needs to be improved. Summary of the Invention

[0003] This application provides a device authentication method and apparatus, which can improve the accuracy of device legitimacy authentication. The technical solution is as follows:

[0004] In a first aspect, this application relates to a device authentication method, comprising: obtaining target verification information and a verification file corresponding to a target device, wherein the target verification information is used to indicate the identification information of the target device, and the verification file is used to indicate the initial identification information of the target device at the time of manufacture; and determining the legitimacy of the target device based on the target verification information and the verification file.

[0005] According to the method described above in this application, since the verification document can indicate the initial identification information of the target device when it leaves the factory, based on the target verification information of the target device and the initial identification information of the target device when it leaves the factory, it is possible to determine whether the identification information of the target device has changed, and thus determine whether there are problems such as counterfeiting or malicious cross-selling of the target device after it leaves the factory, so as to determine the legitimacy of the target device and improve the accuracy of the legality certification of the device.

[0006] In one possible implementation, determining the legitimacy of the target device based on the target verification information and the verification file includes: determining the target device as a legitimate device if the initial identification information indicated by the target verification information and the verification file is consistent.

[0007] In the above implementation, the legitimacy of a target device is determined by comparing the target verification information with the initial identification information indicated in the verification file. Specifically, if the target verification information matches the identification information at the time of manufacture, the target device is considered legitimate; otherwise, it is considered illegitimate. This method of comparing identification information ensures the accuracy of device legitimacy authentication.

[0008] In one possible implementation, the target verification information includes at least one of a device identifier, a chip identifier, and a software identifier; the verification file includes the initial identification information, which includes at least one of an initial device identifier, an initial chip identifier, and an initial software identifier; the method further includes: if the device identifier and the initial device identifier are consistent, the chip identifier and the initial chip identifier are consistent, and the software identifier and the initial software identifier are consistent, determining that the target verification information and the initial identification information indicated by the verification file are consistent.

[0009] In the above implementation method, the legitimacy of the target device is verified by comparing different types of identifiers one by one, from three aspects: device identifier, chip identifier, and software identifier. When all three types of identifiers are consistent, the target device is considered legitimate as it matches the initial identifier information indicated by the target verification information and the verification file. This improves the comprehensiveness of the target device verification and further enhances the accuracy of device authentication.

[0010] In one possible implementation, the verification file includes a first verification parameter, which is a verification parameter generated based on the initial identification information. The method further includes: determining a second verification parameter based on the target verification information; and determining that the target verification information is consistent with the initial identification information indicated by the verification file if the second verification parameter and the first verification parameter are consistent.

[0011] In the above implementation, the legitimacy of the target device is verified by checking whether the first verification parameter and the second verification parameter are consistent. This eliminates the need to compare each identifier indicated by the target verification information; it only requires determining the second verification parameter corresponding to the target verification information and then comparing whether the second verification parameter is consistent with the first verification parameter in the verification file. This achieves legitimate authentication of the target device, thereby improving the flexibility of device authentication.

[0012] In one possible implementation, the method further includes: determining the target validity level of the target device based on the target verification information and the verification file; and controlling the target device to work with the work permissions corresponding to the target validity level based on the target validity level, wherein different validity levels correspond to different work permissions.

[0013] In the above implementation method, by dividing the legality level and work permissions, the consequences of illegal devices are distinguished, so as to achieve a balance between reducing the harm of illegal devices and ensuring the user experience, and improve the flexibility of device authentication.

[0014] In one possible implementation, the verification file is an encrypted file, and the method further includes: determining the legitimacy of the verification file; if the verification file is a legitimate file, decrypting the verification file; if the verification file is successfully decrypted, performing the step of determining the legitimacy of the target device based on the target verification information and the verification file; or, if the verification file cannot be successfully decrypted, determining the target device as an illegitimate device.

[0015] In the above implementation method, when performing legitimate authentication of the device, the legitimacy of the verification file and whether the verification file can be successfully decrypted are first determined to determine whether the data in the verification file has been accidentally modified or damaged, so as to prevent malicious users from forging and destroying the verification file, thereby ensuring the security of the verification file during the device authentication process and ensuring the accuracy of device authentication.

[0016] In one possible implementation, before obtaining the target verification information and verification file corresponding to the target device, the method further includes: determining the initial identification information of the target device, the initial identification information including at least one of an initial device identifier, an initial chip identifier, and an initial software identifier; generating a verification file corresponding to the target device based on the initial identification information; and writing the verification file to the target device.

[0017] In the above implementation method, by generating and writing verification files, it is possible to perform legality authentication on target devices based on actual usage needs in subsequent use processes even when the target devices do not have the conditions for device authentication, thereby enriching the usage scenarios of device authentication.

[0018] In one possible implementation, generating a verification file corresponding to the target device based on the initial identification information includes: determining a first verification parameter based on the initial identification information; and generating a verification file corresponding to the target device based on the first verification parameter.

[0019] In the above implementation, by generating a first verification parameter, the legitimacy of the target device can be verified based on the first verification parameter and the identification information of the target device during device authentication, without having to compare the initial identification information and the identification information of the target device one by one, thereby improving the device authentication efficiency.

[0020] In one possible implementation, before writing the verification file to the target device, the method further includes: encrypting the verification file; writing the verification file to the target device includes: writing the encrypted verification file to the target device.

[0021] In the above implementation method, the security of the verification file is ensured by encrypting it, so as to prevent the initial identification information contained in the verification file from being leaked or maliciously altered, thereby ensuring the accuracy of device authentication.

[0022] Secondly, a device authentication apparatus is provided, comprising: a device driver module, configured to acquire target verification information and a verification file corresponding to a target device, wherein the target verification information is used to indicate the identification information of the target device, and the verification file includes initial identification information corresponding to the target device, wherein the initial identification information is used to indicate the identification information of the target device at the time of manufacture; and an authentication management module, configured to determine the legitimacy of the target device based on the target verification information and the verification file.

[0023] In one possible implementation, the authentication management module includes a device management submodule and an authentication submodule. The device management submodule is configured to receive the target verification information and the verification file obtained by the device driver module, and send an authentication request to the authentication submodule based on the target verification information and the verification file. The authentication submodule is configured to verify the consistency between the target verification information and the initial identification information indicated by the verification file, obtain a first verification result, and send the first verification result to the device management submodule. The device management submodule is further configured to determine the legitimacy of the target device based on the first verification result.

[0024] In one possible implementation, the device management submodule is specifically configured to: determine that the target device is a legitimate device when the first verification result indicates that the target verification information and the initial identification information indicated by the verification file are consistent.

[0025] In one possible implementation, the target verification information includes at least one of a device identifier, a chip identifier, and a software identifier, and the initial identifier information includes at least one of an initial device identifier, an initial chip identifier, and an initial software identifier; the authentication submodule is specifically configured to: determine that the target verification information is consistent with the initial identifier information indicated by the verification file when the device identifier and the initial device identifier are consistent, the chip identifier and the initial chip identifier are consistent, and the software identifier and the initial software identifier are consistent.

[0026] In one possible implementation, the verification file further includes a first verification parameter, which is a verification parameter generated based on the initial identification information; the authentication submodule is further configured to determine a second verification parameter based on the target verification information; verify the consistency between the second verification parameter and the first verification parameter to obtain a second verification result; the device management submodule is further configured to determine the legitimacy of the target device based on the first verification result and the second verification result.

[0027] In one possible implementation, the device management submodule is specifically configured to: determine that the target device is a legitimate device when the target verification information is consistent with the initial identification information indicated by the verification file and the second verification parameter is consistent with the first verification parameter.

[0028] In one possible implementation, the device management submodule is further configured to send illegal authentication information to the device driver module if the target device is an illegal device; the device driver module is further configured to refuse to drive the target device to work upon receiving the illegal authentication information.

[0029] In one possible implementation, the device management submodule is further configured to: determine the target legality level of the target device based on the first verification result and the second verification result, wherein different legality levels correspond to different work permissions; generate a target level control instruction based on the target legality level, and send the target level control instruction to the device driver module, wherein different legality levels correspond to different level control instructions; the device driver module is further configured to control the target device to work with the work permissions corresponding to the target legality level based on the target level control instruction.

[0030] In one possible implementation, the verification file is an encrypted file, and the device management module is further configured to: determine the legality of the verification file; if the verification file is a legal file, decrypt the verification file; if the verification file is successfully decrypted, execute the step of determining the legality of the target device based on the target verification information and the verification file; if the verification file cannot be successfully decrypted, determine that the target device is an illegal device.

[0031] Thirdly, a device authentication apparatus is provided, comprising: a memory and a processor, the memory being used to store computer instructions, and the processor being used to retrieve and execute the computer instructions from the memory to implement the method as described in the first aspect or any implementation thereof.

[0032] Fourthly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a processor, implement the method as described in the first aspect or any implementation thereof.

[0033] Fifthly, a computer program product is provided, the computer program product including instructions that, when executed on a processor, implement the method as described in the first aspect or any of the implementations of the first aspect.

[0034] The technical effects produced by any of the second to fifth aspects and any of the above-mentioned implementation methods can be referred to the first aspect and the corresponding implementation methods in the first aspect. The repetitions will not be repeated here. Attached Figure Description

[0035] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 A schematic diagram of the architecture of a device provided in an embodiment of this application;

[0037] Figure 2 This is a schematic diagram of the architecture of a device authentication system provided in an embodiment of this application;

[0038] Figure 3 A schematic flowchart illustrating a device authentication method provided in an embodiment of this application;

[0039] Figure 4 This is a schematic diagram of the architecture of another device provided in an embodiment of this application;

[0040] Figure 5 This is a schematic diagram of the architecture of another device provided in an embodiment of this application;

[0041] Figure 6 A flowchart illustrating another device authentication method provided in this application embodiment;

[0042] Figure 7 A flowchart illustrating another device authentication method provided in this application embodiment;

[0043] Figure 8 A flowchart illustrating another device authentication method provided in this application embodiment;

[0044] Figure 9 A flowchart illustrating another device authentication method provided in this application embodiment;

[0045] Figure 10 A flowchart illustrating another device authentication method provided in this application embodiment;

[0046] Figure 11 A flowchart illustrating another device authentication method provided in this application embodiment;

[0047] Figure 12 This application provides a schematic diagram of the architecture of a device authentication apparatus.

[0048] Figure 13 A schematic diagram of the architecture of another device authentication device provided in this application embodiment;

[0049] Figure 14 This is a schematic diagram of the architecture of another device authentication device provided in this application embodiment. Detailed Implementation

[0050] To enable those skilled in the art to better understand the solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0051] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Here, A and B can be single or multiple. "At least one of the following" or similar expressions are used to represent any combination of the listed items. For example, at least one of A, B, and / or C can represent: A existing alone, B existing alone, C existing alone, A and B existing simultaneously, B and C existing simultaneously, A and C existing simultaneously, and A, B, and C existing simultaneously. Here, A, B, and C can be single or multiple.

[0052] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0053] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0054] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0055] The technical solutions provided in the embodiments of this application are described below:

[0056] Currently, counterfeit products of various communication devices such as GE (Gigabit Ethernet) and 10GE are emerging in large numbers. Malicious users usually counterfeit products by copying program code and using chips and hardware in parallel. Since the copied code is complete and legitimate, and the chips and hardware components of the device are also legitimate modules, the management equipment cannot identify the abnormality, so that the counterfeit products can be indistinguishable from the real ones during use.

[0057] Specifically, in combination Figure 1 , Figure 1 An example is shown in the schematic diagram of the architecture of a device.

[0058] like Figure 1 As shown, devices typically have various serial numbers (SNs) recorded after leaving the factory, such as the Device Serial Number (DSN), also known as the device SN, which is used to uniquely identify the device. In some scenarios, the device may be equipped with at least one chip (such as...). Figure 1 The device contains chips 1, 2, and 3, which perform different functions. These chips are typically distinguished by their Chip Serial Number (CSN), also known as the chip SN. Furthermore, in some scenarios, the device also includes software to control and manage its functions, such as an operating system and drivers. This software uses a Software Serial Number (SSN), also known as the software SN, to identify the version of the software installed on the target device.

[0059] In some embodiments, the device administrator can typically authenticate the device by determining whether the device serial number (SN), chip serial number (SN), and software serial number (SN) are legitimate. However, in order to circumvent the administrator's authentication review of the device's legitimacy, malicious users directly copy the device serial number, chip serial number, software serial number, and other identifiers of legitimate devices, or directly combine the chips, motherboards, and other modules of devices from other regions (which are usually prohibited from distribution) with other modules from this region for cross-regional sales, thereby obtaining counterfeit "legitimate" devices.

[0060] To address the aforementioned issues, this application proposes a device authentication method and apparatus that can improve the comprehensiveness of device authentication, thereby enhancing its accuracy.

[0061] To facilitate understanding of the technical solutions provided in the embodiments of this application, the application scenarios of the embodiments of this application are illustrated below:

[0062] like Figure 2 The diagram shown is an architectural schematic of a device authentication system provided in this embodiment. The device authentication system includes a device to be authenticated 21, a system device 22, and an authentication center 23.

[0063] The device to be certified 21 is a specific functional product, such as an optical module used to convert electrical signals into optical signals or optical signals into electrical signals.

[0064] System device 22 is the basic equipment for specific use scenarios. For example, if the device to be authenticated 21 is an optical module, system device 22 can be a switch, router, firewall or server, etc., used to forward and process data packets. In this case, system device 22 may include a device interface (not shown in the figure) that can support the insertion of optical modules, so as to connect with the optical module through the device interface and realize fiber optic transmission with remote devices through the optical module.

[0065] The certification center 23 is used to verify the legitimacy of the device 21 to be certified. The system device 22 can be connected to the certification center 23 to verify the legitimacy of the device 21 to be certified through the certification center 23.

[0066] For example, after the device to be certified 21 is inserted into the system device 22, the system device 22 can obtain the target verification information and verification file corresponding to the device to be certified 21, and send the target verification information and verification file to the certification device, so as to realize the legitimacy certification of the device to be certified 21 through the certification center 23 based on the target verification information and verification file.

[0067] In some embodiments, the authentication center 23 may also be integrated into the system device 22 to optimize the data flow and communication path between the system device 22 and the authentication center 23, improve the speed and efficiency of data processing, and thereby improve the authentication efficiency of the device to be authenticated.

[0068] It should be noted that the above description is merely an example of the structure of the device authentication system applicable to this embodiment. In actual applications, the technical solution provided in this embodiment can also be applied to other device authentication systems with simpler or more complex structures. This embodiment does not impose any restrictions on the system structure of the device authentication system.

[0069] Figure 3This is a flowchart illustrating a device authentication method provided in an embodiment of this application. This method can be executed by the entire or part of the aforementioned system device. This embodiment illustrates the method by example, with the entire system device executing it. Other executing entities can refer to the operation of the system device for execution. The method includes steps S101 to S102.

[0070] S101: Obtain the target verification information and verification file corresponding to the target device. The target verification information is used to indicate the identification information of the target device, and the verification file is used to indicate the initial identification information of the target device when it leaves the factory.

[0071] Optionally, the target device may include a memory to store target verification information and verification files. In this case, the system device can obtain the target verification information and verification files by reading the information stored in the memory.

[0072] It should be noted that the identification information of the target device indicated by the target verification information can be understood as: the identification information that the target device obtains in real time during use, that is, the current identification information of the target device; while the initial identification information included in the verification file can be understood as: the initial identification information of the target device after it has completed production, that is, when the target device leaves the factory.

[0073] In legitimate scenarios, where the target device is not involved in parallel imports or counterfeiting, the target verification information corresponding to the target device should be consistent with the initial identification information indicated in the verification file. However, when malicious users alter or counterfeit devices through parallel imports (e.g., replacing chip 'a' in target device A with chip 'b' in device B) or counterfeiting (e.g., copying the entire software code of device B onto target device A), the identification information of each component cannot match the initial identification information included in the verification file because all or part of the device's components (e.g., the device body, chips, and / or software) have been replaced. Therefore, the legitimacy of the target device can be authenticated based on the target verification information corresponding to the target device and the verification file.

[0074] S102: Determine the legitimacy of the target device based on the target verification information and verification file.

[0075] In some embodiments, the target device can be determined to be a legitimate device if the target verification information and the initial identification information indicated by the verification file are consistent.

[0076] It should be noted that consistency between the target verification information and the initial identification information indicated in the verification file means that the identification information of the target device shown in the target verification information is consistent with the initial identification information indicated in the verification file. This indicates that the target device has not been counterfeited or maliciously sold outside the factory, and therefore the target device can be determined to be legitimate.

[0077] Optionally, if the target verification information and the initial identification information indicated by the verification file are inconsistent, the target device can be determined to be an illegal device.

[0078] In some embodiments, the target verification information includes at least one of a device identifier, a chip identifier, and a software identifier, and the verification file includes initial identification information, which includes at least one of an initial device identifier, an initial chip identifier, and an initial software identifier. If the device identifier and the initial device identifier are the same, the chip identifier and the initial chip identifier are the same, and the software identifier and the initial software identifier are the same, it can be determined that the target verification information and the initial identification information indicated by the verification file are consistent.

[0079] The device identifier can be the aforementioned device SN, the chip identifier can be the aforementioned chip SN, and the software identifier can be the aforementioned software SN. Furthermore, in some scenarios, the specific identifier type included in the target verification information can change depending on the type of the target device. That is, the type of target verification information corresponding to different target device types may also differ. For example, if the target device is an optical module, the target verification information may only include the device identifier.

[0080] In some embodiments, the device identifier of the target device can be an electronic tag of the target device. However, considering that in some scenarios the electronic tag of the target device can be quite complex, such as the electronic tag of the target device possibly including various device information, in order to reduce the complexity of the device identifier, the hash digest of the electronic tag of the target device can be used as the device identifier of the target device.

[0081] In addition, in some scenarios, the target device may be equipped with multiple chips and multiple software programs. In such scenarios, the target verification information corresponding to the target device includes multiple chip identifiers and multiple software identifiers.

[0082] It should be noted that the target verification information will differ depending on the target device, and the second verification information included in the verification file will also vary. For example, taking the aforementioned optical module as an example, since the optical module only includes a device identifier, the verification text can include only the initial device identifier. Therefore, the legitimacy of the optical module can be determined based on the device identifier corresponding to the optical module and the initial device identifier in the verification file. As another example, if the target device has multiple chip identifiers, then the target verification information corresponding to the target device should include multiple chip identifiers, and the verification file corresponding to the target device should also include multiple initial chip identifiers, so that the legitimacy of the target device can be determined based on the multiple chip identifiers of the target device and the multiple initial chip identifiers included in the verification file.

[0083] In some embodiments, if the number and type of device identifiers included in the target verification information are inconsistent with the number and type of identifiers indicated in the verification file, it can be directly assumed that the target verification information and the initial identifiers indicated in the verification file are inconsistent, thereby determining that the target device is an illegal device.

[0084] For example, the initial identification information corresponding to the target device includes an initial device identifier, two initial chip identifiers, and an initial software identifier. If the target verification information corresponding to the target device includes a device identifier, a chip identifier, and a software identifier, since the number of chip identifiers included in the target verification information is not consistent with the number of chip identifiers included in the initial identification information, it can be directly assumed that the target verification information and the initial identifier indicated by the verification file are inconsistent, thereby determining that the target device is an illegal device.

[0085] In other embodiments, considering that the target device may be compatible with multiple chips and multiple software during use, in some scenarios, one of the identifiers included in the target device can be one of the preset identifiers. For example, the target device may be equipped with a chip identified as B1. However, in some cases, this chip can be replaced with a chip identified as B2. That is, in some embodiments, the initial identifier information indicated by the verification file may be less than the identifier information indicated by the target verification information. In this case, if the initial identifier information indicated by the verification file includes all the identifier information included in the target verification information, the target verification information and the initial identifier information indicated by the verification file can be considered to be consistent.

[0086] For example, the initial identification information corresponding to the target device may include initial device identifier A, initial chip identifier B1, initial chip identifier B2, initial chip identifier B3, initial software identifier C1, and initial software identifier C2. In this case, if the target verification information corresponding to the target device includes initial device identifier A, initial chip identifier B1, and initial software identifier C2, then it can be considered that the target verification information is consistent with the initial identification information indicated by the verification file.

[0087] In some embodiments, the verification file includes a first verification parameter, which is a verification parameter generated based on initial identification information. A second verification parameter can be determined based on the target verification information. If the second verification parameter and the first verification parameter are consistent, it is determined that the target verification information and the initial identification information indicated by the verification file are consistent.

[0088] In some embodiments, a specific algorithm can be identified, whereby the parameters obtained by the specific algorithm based on the same information will be the same, and the parameters obtained by the specific algorithm based on different information will be different. Then, a second verification parameter is determined based on the target verification information using the specific algorithm; the first verification parameter included in the verification file can also be a verification parameter determined based on the initial identification information using the specific algorithm. This ensures that, if the identification information of the device indicated by the target verification information and the initial identification information indicated by the verification file are consistent, the second verification parameter obtained according to the specific algorithm and the first verification parameter included in the verification file will be consistent. That is, if the second verification parameter obtained based on the target verification information and the first verification parameter included in the verification file are consistent, the identification information indicated by the target verification information and the initial device information indicated by the verification file will be consistent, thereby further improving the accuracy of device authentication.

[0089] In some scenarios, the first verification parameter can be a first hash digest calculated using a target hash function based on the initial identification information. After obtaining the target verification information and the first verification parameter, the system device can calculate a second hash digest using the target hash function based on the target verification information. It can then compare the first and second hash digests to determine if they match. If they do, the system device is deemed to be legitimate, as the target verification information matches the initial identification information indicated by the verification file.

[0090] In this way, when the target verification information corresponding to the target device includes multiple identification information (such as device identifier, multiple chip identifier and multiple software identifier), it is not necessary to compare the identifiers one by one. It is only necessary to determine the second verification parameter corresponding to the target verification information, and then compare whether the second verification parameter is consistent with the first verification parameter in the verification file. This can realize the legitimacy authentication of the target device and improve the authentication efficiency of the target device.

[0091] In some embodiments, the verification file may simultaneously include initial identification information and first verification parameters. If the target verification information corresponding to the target identifier is consistent with the initial identification information, and the second verification parameters determined based on the target verification information are consistent with the first verification parameters, then the target verification information is determined to be consistent with the initial identification information indicated by the verification file. This allows for multi-faceted authentication of the target device based on whether the first and second verification parameters are consistent, and whether the first verification parameters are consistent with the initial identification information, thereby improving the comprehensiveness and accuracy of device authentication.

[0092] In some embodiments, the target validity level of the target device can be determined based on the target verification information and verification file; based on the target validity level of the target device, the target device can be controlled to work with the working permissions corresponding to the target validity level, and different validity levels correspond to different working permissions.

[0093] Based on the above description, since the embodiments of this application involve multi-faceted authentication of the target device identification information, such as when the target device includes multiple identifiers (e.g., two chip identifiers, two software identifiers, or one chip identifier and one software identifier), the harm caused by using the target device is minimal if some components of the target device are used in unauthorized transactions (i.e., some of the identifiers in the target verification information contain invalid identifiers that are inconsistent with the initial identification information). Therefore, to improve the flexibility of device authentication, the legitimacy level of the target device can be divided, and its use can be restricted through different legitimacy levels.

[0094] For example, based on the target verification information and verification file, the number and type of illegal identifiers in the target verification information of the target device can be determined. Then, based on the number and type of illegal identifiers, the target legality level of the target device can be determined, and the working permissions of the target device can be restricted based on the target legality level.

[0095] The correspondence between the number and type of illegal identifiers and the legal level, as well as the working permissions corresponding to each legal level, can be flexibly selected based on actual usage needs. For example, the legal levels of the target device include five levels, arranged from highest to lowest as legal level one to five. Legal level one means that the target verification information and the initial identifier information indicated by the verification file of the target device are completely consistent. The working permission corresponding to this legal level is the highest working permission, meaning no restrictions are placed on the working permissions of the target device. Legal level three means that the device identifier and software identifier of the target device are consistent with the initial device identifier and initial software identifier indicated by the verification file, and the number of illegal chip identifiers of the target device is less than or equal to two. The working permission corresponding to this legal level is to restrict the execution of functions corresponding to the illegal chip identifiers. Legal level five means that the target verification information and the initial identifier information indicated by the verification file of the target device are completely inconsistent. The working permission corresponding to this legal level is no working permission, meaning all working permissions of the target device are restricted, and the target device is directly powered off.

[0096] For example, the first identification information of the target device includes device identifier A, chip identifiers B1, B2 and B3, and software identifier C. After comparison, it is determined that chip identifiers B2 and B3 of the target device are inconsistent with the initial identifiers indicated by the verification file. Therefore, the target's legality level is determined to be legality level three, and the target device is controlled to work with the working permissions corresponding to legality level three, that is, the execution of the functions corresponding to chip identifier B2 and chip identifier B3 in the target device is restricted.

[0097] In some embodiments, the verification file is an encrypted file, which can be used to determine the legitimacy of the verification file. If the verification file is legitimate, it is decrypted. If the verification file is successfully decrypted, the step of determining the legitimacy of the target device based on the target verification information and the verification file is performed. Alternatively, if the verification file cannot be successfully decrypted, the target device is determined to be an illegitimate device. This allows for the timely detection of whether the data in the verification file has been accidentally altered or corrupted, thereby improving the accuracy and security of device authentication.

[0098] For example, the target device is as follows Figure 4 The device shown includes target verification information, which includes device SN(A), chip SN(A), and software SN(A), as well as an encrypted verification file. Figure 4 If the encrypted file (A) in the verification file indicates the initial identification information of the initial device SN (A), the initial chip SN (A), and the initial software SN (A), then after determining that the verification file is a legitimate file and successfully decrypting the verification file, it can be determined that the target verification information of the target file is consistent with the initial identification information indicated by the verification file, and the target device is considered to be a legitimate device.

[0099] For example, the target device is Figure 5 The device shown includes target verification information, which includes device SN(B), chip SN(B), and software SN(A), as well as an encrypted verification file. Figure 5 If the encrypted file (B) in the verification file indicates the initial identification information of the initial device SN (B), the initial chip SN (B), and the initial software SN (B), then after determining that the verification file is a legitimate file and successfully decrypting the verification file, it can be determined that the target verification information of the target file is inconsistent with the initial identification information indicated by the verification file, and the target device is considered to be an illegal device.

[0100] In some embodiments, the system device may include a driver module and a management module. In this scenario, when implementing the device authentication method of this application embodiment, the interaction flow between the modules of the system device and with the authentication center can be as follows: Figure 6 As shown.

[0101] When the target device is in use, such as when the aforementioned optical module is inserted into the system device, the driver module acquires and reports the target verification information and verification file of the target device to the management module;

[0102] The management module sends a verification request to the authentication module based on the target verification information and the verification file;

[0103] The authentication module verifies the consistency between the target verification information and the initial identification information indicated by the verification file, generates and reports the verification results to the management module;

[0104] The management module determines the legitimacy of the target device based on the verification result. If the target verification information matches the initial identification information indicated in the verification file, a device authentication legitimacy notification is sent, enabling the driver module to drive the target device to work normally. If the target verification information does not match the initial identification information indicated in the verification file, a device authentication invalidity notification is sent, causing the driver module to send an alarm and power down the target device.

[0105] Furthermore, considering that in some scenarios the target device may not include a verification file, to ensure proper authentication of the target device, a verification file corresponding to the target device can be generated and written to the target device before step S101, such as during the target device's production process, before it leaves the factory, or before it is put into use. This way, for target devices that have already completed production, the written verification file can be used to achieve legality authentication during subsequent device use, further enriching the application scenarios of this application.

[0106] As an example, Figure 7 This is a schematic diagram of a verification file generation and writing process provided in an embodiment of this application, combined with... Figure 7 The process of generating and writing verification files can be implemented through S201 to S203.

[0107] S201: Determine the initial identification information of the target device. The initial identification information includes at least one of the following: device identifier, chip identifier, and software identifier.

[0108] It should be noted that after the target device is manufactured, since the various chips and software installed on the target device are already determined, the various identification information of the target device can be determined based on the production information of the target device.

[0109] It is understandable that due to variations in device type and usage scenarios, the chips and software required by a device may differ. For example, in some simpler functional scenarios, the target device may not need to include any chips or software, and in such cases, the device's identification information may only include a single device identifier. Conversely, in more complex functional scenarios, the target device may have multiple chips or even multiple software programs, and in such cases, the device's identification information may include a device identifier, multiple chip identifiers, and multiple software identifiers. In other words, the quantity and type of the target device's identification information can be flexibly selected based on actual usage requirements.

[0110] S202: Generate a verification file corresponding to the target device based on the initial identification information.

[0111] In some embodiments, a first verification parameter can be determined based on initial identification information; and a verification file corresponding to the target device can be generated based on the first verification parameter.

[0112] The format of the verification file corresponding to the target device can be flexibly selected based on actual usage requirements. For example, the verification file can be a text file. In this case, a text file containing the identification information can be generated based on the identification information, thereby obtaining the verification file.

[0113] Optionally, the method for determining the first verification parameter can also be flexibly determined based on actual usage requirements. For example, the first verification parameter can be determined based on the initial identification information through a specific parameter calculation method.

[0114] For example, the first verification parameter can be a hash digest obtained by hashing each identifier using a hash function. Then, based on the identifier and the hash digest, a verification file corresponding to the target device is generated and written to the target device. In this way, if a malicious user needs to forge a verification file, they not only need to obtain the identifier of the target device but also the specific method for determining the first verification parameter, thereby improving the security of the verification file and preventing it from being forged by malicious users.

[0115] In some embodiments, the first verification parameter can also be determined based on both identification information and authentication parameters. The authentication parameter can be flexibly determined by the equipment manufacturer or other equipment production management party based on security requirements. That is, if a malicious user needs to generate a verification file based on the identification information of the target device after cross-selling, it not only needs to obtain all the identification information of the target device after cross-selling and the specific method for determining the first verification parameter (such as the specific hash function mentioned above), but also needs to obtain the authentication parameter used in the generation process of the first verification parameter, so as to further improve the security of the verification file and prevent it from being forged by malicious users.

[0116] In some embodiments, a verification file for the target device can also be generated based on the initial identification information and the first verification parameter. That is, the verification file includes both the initial identification information and the first verification parameter determined based on the initial identification information. In this scenario, when authenticating the target device, the target device can be determined to be a legitimate device if the target device's identification information matches the initial identification information and the second verification parameter determined based on the target device's identification information matches the first verification parameter.

[0117] S203: Write the verification file to the target device.

[0118] In some embodiments, to further enhance the security of the verification file, the verification file may be encrypted; and the encrypted verification file may be written to the target device.

[0119] It should be noted that since the generation and writing of the verification file is not logically continuous with the authentication process of the target device, in some embodiments, the above-mentioned S201 to S203 can also be executed by other devices, such as generating and writing the verification file through the production software of the target device during the production process of the target device.

[0120] The following section will provide a further introduction to this application in conjunction with specific use cases.

[0121] Scenario 1: Simple equipment scenario.

[0122] In simple device scenarios, such as optical modules, it is usually necessary to write a verification file into the optical module. The process of writing the verification file is illustrated as follows: Figure 8 As shown.

[0123] Combination Figure 8 First, obtain the device identifier of the optical module, i.e., the optical module SN in the figure. Then, generate a verification file based on the optical module SN and write the verification file to the optical module.

[0124] In some embodiments, such as Figure 8 As shown, after obtaining the optical module SN, the optical module SN can be signed by the production software to obtain the signed data. The signed data is then used as a verification file to ensure the integrity of the verification file and the authenticity of the file source.

[0125] In other embodiments, when signing the optical module SN, encryption can also be performed based on a specific encryption algorithm. The specific encryption algorithm can be flexibly selected according to actual usage requirements, such as asymmetric encryption algorithm, symmetric encryption algorithm, etc.

[0126] For example, the verification file can be encrypted based on the Rivest-Shamir-Adleman (RSA) algorithm, and the encrypted verification file can be written to the optical module.

[0127] Optionally, the generation and writing of the verification file can be carried out during the optical module production process, such as by using the optical module production equipment and corresponding production software; or the verification file can be generated and written by the system equipment during the use of the optical module for reasons such as authentication requirements.

[0128] During the use of optical modules, the authentication process for optical modules is as follows: Figure 9 As shown.

[0129] Combination Figure 9 After the optical module is inserted into the system device, the system device obtains the target verification information of the optical module, that is... Figure 9 The system device also needs to obtain the optical module's serial number (SN). Furthermore, it needs to acquire the optical module's verification file and compare the initial identification information indicated in the verification file with the target verification information; that is, it compares whether the optical module SN included in the verification file matches the current optical module SN. If the optical module SN indicated in the verification file matches the current optical module SN, the current optical module is considered a legitimate device, authentication is successful, and the optical module is driven to work normally. If the optical module SN indicated in the verification file does not match the current optical module SN, the current optical module is determined to be an illegitimate device, authentication fails, and the optical module is refused to work normally.

[0130] In some embodiments, such as Figure 9 As shown, if the verification file is an encrypted signature file, the signature file needs to be decrypted and designed before comparing the initial identification information indicated by the verification file with the target verification information. If both decryption and designing are successful (i.e., the verification file is successfully decrypted and the signature is verified to be correct), the legitimacy of the optical module is then determined based on the optical module SN indicated by the verification file and the corresponding optical module SN.

[0131] Scenario 2: Complex equipment scenarios.

[0132] In some complex device scenarios, such as highly integrated communication devices like mobile phones and computers, it is possible to base on... Figure 10 The process shown implements the writing of the verification file.

[0133] It should be noted that, as mentioned above, the verification file corresponding to the communication device usually contains the device identifier, chip identifier, and software identifier simultaneously. However, in some scenarios, it may only contain some of the device identifier, chip identifier, and software identifier. This example illustrates the case where the device identifier, chip identifier, and software identifier are all present. Other cases can be handled in the same way as the case where the device identifier, chip identifier, and software identifier are all present.

[0134] Combination Figure 10 First, the device identifier, chip identifier, and software identifier of the communication device are obtained. Then, based on the device identifier, chip identifier, and software identifier of the communication device, a CSR (Certificate Signing Request) file is generated. Based on the CSR file, an identity certificate (equivalent to the verification file mentioned above) is requested from the PKI (Public Key Infrastructure) system. The identity certificate sent by the PKI system is received and loaded into the communication device.

[0135] In some embodiments, to further enhance the security of identity certificates, PKI can sign the identity certificate after generating it and send the signed identity certificate.

[0136] Similarly, in conjunction with the above scenario one, the generation and writing process of identity certificates can be carried out during the production process of communication equipment. For example, it can be implemented based on the production equipment and corresponding production software of the communication equipment during the production process, or it can be generated and written by the system equipment for authentication needs or other reasons during the use of the communication equipment.

[0137] In the subsequent use of communication equipment, the authentication process for the communication equipment is as follows: Figure 11 As shown.

[0138] Combination Figure 11 After the communication device starts up, it first verifies the device's identity certificate, checking its legality and integrity. If the identity certificate is legal and complete, it is decrypted to obtain the device identifier, chip identifier, and software identifier from the identity document. Then, it verifies whether the device identifier matches the one in the identity document, whether the chip identifier matches the one in the identity certificate, and whether the software identifier matches the one in the identity document, thus authenticating the communication device's legitimacy.

[0139] If the device identifier of the communication device matches the device identifier in the ID card, the chip identifier of the verification communication device matches the chip identifier of the identity certificate, and the software identifier of the communication device matches the software identifier in the ID card, the communication device will work normally; otherwise, the communication device will be determined to be an illegal device.

[0140] In cases where the device identifier of the communication device does not match the device identifier in the ID card, the chip identifier of the communication device does not match the chip identifier of the identity certificate, and / or the software identifier of the communication device does not match the software identifier in the ID card, an alarm message can be sent, such as a cross-selling alarm message, and the communication device can be forcibly taken offline. Optional, such as... Figure 11 As shown, in cases where the device identifier of the communication device is inconsistent with the device identifier in the ID card, the chip identifier of the verification communication device is inconsistent with the chip identifier of the identity certificate, and / or the software identifier of the communication device is inconsistent with the software identifier in the ID card, the working permissions of the communication device can be restricted based on the specific illegal identifier type.

[0141] In the above embodiments, by using the identification information of the target device indicated by the target verification file and the initial identification information indicated by the verification file, it is determined whether the identification information of the target device is abnormal, thereby promptly detecting problems such as counterfeiting and cross-selling of the target device, and thus determining the legitimacy of the target device. For example, in some embodiments, the legitimacy of the target device can be verified from three aspects: device identification, chip identification, and software identification. If the device identification, chip identification, and software identification of the target device are all correct, the target device is determined to be a legitimate device. In addition, considering that the verification information of the target device may include multiple items, a first verification parameter is set in the verification file to improve the efficiency of device authentication. In this way, after obtaining the target verification information of the target device, it is only necessary to determine the second verification parameter based on the target verification information, and then compare whether the second verification parameter is consistent with the first verification parameter to realize the legitimacy of the target device, without having to compare the identification information of the target device one by one, thereby improving the efficiency of device authentication.

[0142] Furthermore, considering that counterfeit or parallel-sold devices may pose a relatively minor threat in some scenarios, the legitimacy of target devices is categorized. During device authentication, the target device's legitimacy level is determined based on the target verification information and verification files. This legitimacy level then restricts the target device's access permissions. This approach not only protects the legitimate rights and interests of businesses by restricting unauthorized devices but also ensures a positive user experience, thereby enhancing the flexibility of device authentication.

[0143] Furthermore, the verification file can also be encrypted. This allows the verification file's legitimacy to be verified first during device authentication, and legitimate verification files can be decrypted. This prevents malicious users from altering or stealing data from the verification file, ensuring its security and thus guaranteeing the accuracy of device authentication.

[0144] Furthermore, considering that the target device may not have a verification file in some scenarios, the initial identification information of the target device is obtained, and a verification file is generated and written to the target device based on this information. This allows for on-the-spot authentication of the target device based on actual usage needs during subsequent use, enriching the application scenarios of device authentication. Additionally, when generating the verification file, a first verification parameter can be generated based on the initial identification information of the target device. This eliminates the need for one-to-one comparison of identification information during subsequent device authentication; only the second verification parameter corresponding to the target device's identification information needs to be determined. Authentication of the target device can then be achieved based on the second verification parameter and the first verification parameter included in the verification file, thereby improving authentication efficiency. Furthermore, the verification file is encrypted and written to the target device. This ensures the security of the verification file, preventing it from being stolen or altered by malicious users, thus guaranteeing the accuracy of subsequent device authentication.

[0145] The above text combines Figures 3-11 This document describes in detail the device authentication method provided according to this embodiment. The following will describe the various devices corresponding to the device authentication method provided in this embodiment.

[0146] like Figure 12 The diagram shown is a structural schematic of a device authentication device provided in this embodiment. The device authentication device 30 can be a software / hardware device for task scheduling. Specifically, the device authentication device 30 can include desktop computers, tablets, desktop-type, laptop-type, handheld computers, laptops, ultra-mobile personal computers (UMPCs), netbooks, cellular phones, personal digital assistants (PDAs), augmented reality (AR) / virtual reality (VR) devices, and various artificial intelligence (AI) hardware accelerators, etc., capable of device authentication. Alternatively, the device authentication device 30 can also be software running on the aforementioned devices.

[0147] The device authentication device 30 can be used to perform the above-mentioned... Figures 3-11All or part of the steps performed in the process. Specifically, the device authentication device 30 includes:

[0148] Device driver module 31 is used to obtain target verification information and verification file corresponding to the target device. The target verification information is used to indicate the identification information of the target device, and the verification file is used to indicate the initial identification information of the target device when it leaves the factory.

[0149] The authentication management module 32 is used to determine the legitimacy of the target device based on the target verification information and verification file.

[0150] In some embodiments, such as Figure 13 As shown, the authentication management module 32 includes a device management submodule 321 and an authentication submodule 322;

[0151] The device management submodule 321 is used to receive the target verification information and verification file obtained by the device driver module 31, and send an authentication request to the authentication submodule 322 based on the target verification information and verification file.

[0152] The authentication submodule 322 is used to verify the consistency between the target verification information and the initial identification information indicated by the verification file, obtain the first verification result, and send the first verification result to the device management submodule 321;

[0153] The device management submodule 321 is also used to determine the legitimacy of the target device based on the first verification result.

[0154] In some embodiments, the device management submodule 321 is specifically used for:

[0155] If the first verification result indicates that the target verification information and the initial identification information indicated in the verification file are consistent, the target device is determined to be a legitimate device.

[0156] In some embodiments, the target verification information includes at least one of device identifier, chip identifier, and software identifier, and the initial identifier information includes at least one of initial device identifier, initial chip identifier, and initial software identifier;

[0157] The authentication submodule 322 is specifically used to: verify the consistency between the device identifier and the initial device identifier, the chip identifier and the initial chip identifier, and the software identifier and the initial software identifier to obtain a second verification result; if the second verification result indicates that the device identifier and the initial device identifier are consistent, the chip identifier and the initial chip identifier are consistent, and the software identifier and the initial software identifier are consistent, determine that the target verification information is consistent with the initial identifier information indicated by the verification file.

[0158] In some embodiments, the verification file further includes a first verification parameter, which is a verification parameter generated based on the initial identification information;

[0159] The authentication submodule 322 is also used to determine a second verification parameter based on the target verification information; verify the consistency between the second verification parameter and the first verification parameter to obtain a third verification result; and determine that the target verification information is consistent with the initial identification information indicated by the verification file if the third verification result indicates that the second verification parameter and the first verification parameter are consistent.

[0160] In some embodiments, the device management submodule 321 is further configured to send illegal authentication information to the device driver module 31 if the first verification result indicates that the target verification information and the initial identification information indicated by the verification file are inconsistent.

[0161] The device driver module 31 is also used to refuse to drive the target device to work when illegal authentication information is received.

[0162] In some embodiments, the device management submodule 321 is further configured to:

[0163] Based on the second and third verification results, the target device's legality level is determined, and different legality levels correspond to different work permissions;

[0164] Based on the target legal level, a target level control instruction is generated and sent to the device driver module 31. Different legal levels correspond to different level control instructions.

[0165] The device driver module 31 is also used to control the target device to work with the working permissions corresponding to the target legal level based on the target level control instructions.

[0166] In some embodiments, the verification file is an encrypted file, and the authentication submodule 322 is further configured to:

[0167] Determine the validity of the verification file;

[0168] If the verification file is found to be valid, decrypt the verification file.

[0169] If the verification file is successfully decrypted, the legitimacy of the target device is determined based on the target verification information and the verification file; or, if the verification file cannot be successfully decrypted, the target device is determined to be an illegitimate device.

[0170] For a more detailed description of the aforementioned device driver module 31, authentication management module 32, management submodule 321, and authentication submodule 322, please refer to [the relevant documentation / reference]. Figures 2-11 The relevant descriptions of the methods shown will not be repeated here.

[0171] In the above embodiments, by using the identification information of the target device indicated by the target verification file and the initial identification information indicated by the verification file, it is determined whether the identification information of the target device is abnormal, thereby promptly detecting problems such as counterfeiting and cross-selling of the target device, and thus determining the legitimacy of the target device. For example, in some embodiments, the legitimacy of the target device can be verified from three aspects: device identification, chip identification, and software identification. If the device identification, chip identification, and software identification of the target device are all correct, the target device is determined to be a legitimate device. In addition, considering that the verification information of the target device may include multiple items, a first verification parameter is set in the verification file to improve the efficiency of device authentication. In this way, after obtaining the target verification information of the target device, it is only necessary to determine the second verification parameter based on the target verification information, and then compare whether the second verification parameter is consistent with the first verification parameter to realize the legitimacy of the target device, without having to compare the identification information of the target device one by one, thereby improving the efficiency of device authentication.

[0172] Furthermore, considering that counterfeit or parallel-sold devices may pose a relatively minor threat in some scenarios, the legitimacy of target devices is categorized. During device authentication, the target device's legitimacy level is determined based on the target verification information and verification files. This legitimacy level then restricts the target device's access permissions. This approach not only protects the legitimate rights and interests of businesses by restricting unauthorized devices but also ensures a positive user experience, thereby enhancing the flexibility of device authentication.

[0173] Figure 14 This is a schematic diagram of another device authentication device provided in this embodiment. The device authentication device 40 can be a chip or a system-on-a-chip. Specifically, the device authentication device 40 can include all or part of the hardware in devices such as desktop computers, tablet computers, desktop-type, laptop computers, handheld computers, notebook computers, super mobile personal computers, netbooks, as well as cellular phones, personal digital assistants, augmented reality / virtual reality devices, and various artificial intelligence hardware accelerators.

[0174] The device authentication device 40 may include some or all of the following components: processor 401, communication line 402, memory 403, and at least one communication interface 404.

[0175] The processor 401 is used to execute this embodiment. Figures 2-11 All or part of the steps performed by the device authentication device in the provided method.

[0176] Specifically, processor 401 may include a general-purpose central processing unit (CPU), and processor 401 may also include a microprocessor, a field-programmable gate array (FPGA), a digital signal processor (DSP), or an application-specific integrated circuit (ASIC), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0177] In a specific implementation, as one example, processor 401 may include one or more CPUs, for example... Figure 14 CPU0 and CPU1 in the CPU.

[0178] In a specific implementation, as one example, the device authentication device 40 may include multiple processors, such as... Figure 14 Processors 401 and 406 are mentioned. Each of these processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor here can refer to one or more devices, circuits, and / or processing cores used to process, for example, data (computer program instructions).

[0179] Additionally, memory 403 can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). Memory 403 may exist independently and be connected to processor 401 via communication line 402. Memory 403 may also be integrated with processor 401.

[0180] The memory 403 stores computer instructions. The processor 401 can execute all or part of the steps in the device authentication method provided in this embodiment by executing the computer instructions stored in the memory 403. For example... Figure 14 As shown, the computer instructions stored in memory 403 may include software modules for implementing the functions of each functional unit in the device authentication apparatus 30 described above. The processor 401 can execute the computer instructions stored in memory 403 to perform the device authentication method provided in this embodiment.

[0181] Optionally, the computer execution instructions in this embodiment may also be referred to as application code, and this embodiment does not specifically limit this.

[0182] In addition, communication interface 404 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), etc.

[0183] In addition, communication line 402 is used to connect the various components in device authentication device 40. Specifically, communication line 402 may include a data bus, power bus, control bus, and status signal bus, etc. However, for clarity, all buses are labeled as communication line 402 in the figure.

[0184] Additionally, the device authentication device 40 may also include a storage medium 405. The storage medium 405 stores computer instructions and various data for implementing the technical solution of this embodiment. This allows the device authentication device 40 to load the computer instructions and various data stored in the storage medium 405 into the memory 403 when executing the device authentication method described above in this embodiment. This enables the processor 401 to execute the device authentication method provided in this embodiment by executing the computer instructions stored in the memory 403.

[0185] The method steps in this embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, PROM, EPROM, EEPROM, registers, hard disk, portable hard disk, CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a device authentication device. Of course, the processor and storage medium can also exist as discrete components in the device authentication device.

[0186] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in this embodiment are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a communication device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).

[0187] In this embodiment, unless otherwise specified or there is a logical conflict, the terms and / or descriptions of different implementations are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0188] In this embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. Other quantifiers are similar. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Furthermore, for elements appearing in the singular forms "a," "an," and "the," unless explicitly specified by the context, it does not mean "one or only one," but rather "one or more than one." For example, "adevice" means one or more such devices. Moreover, "at least one of..." means one or any combination of subsequent related objects. For example, "at least one of A, B, and C" includes A, B, C, AB, AC, BC, or ABC. In the textual description of this embodiment, the character " / " generally indicates an "or" relationship between the preceding and following related objects; in the formula of this embodiment, the character " / " indicates a "division" relationship between the preceding and following related objects.

Claims

1. A device authentication method, characterized in that, include: Obtain target verification information and verification file corresponding to the target device. The target verification information is used to indicate the identification information of the target device, and the verification file is used to indicate the initial identification information of the target device when it leaves the factory. The legitimacy of the target device is determined based on the target verification information and the verification file.

2. The method according to claim 1, characterized in that, The step of determining the legitimacy of the target device based on the target verification information and the verification file includes: If the target verification information and the initial identification information indicated by the verification file are consistent, the target device is determined to be a legitimate device.

3. The method according to claim 2, characterized in that, The target verification information includes at least one of device identifier, chip identifier, and software identifier; the verification file includes the initial identifier information, which includes at least one of initial device identifier, initial chip identifier, and initial software identifier. The method further includes: If the device identifier is consistent with the initial device identifier, the chip identifier is consistent with the initial chip identifier, and the software identifier is consistent with the initial software identifier, then the target verification information is determined to be consistent with the initial identifier information indicated by the verification file.

4. The method according to claim 2 or 3, characterized in that, The verification file includes a first verification parameter, which is a verification parameter generated based on the initial identification information. The method further includes: The second verification parameter is determined based on the target verification information; If the second verification parameter and the first verification parameter are consistent, it is determined that the target verification information is consistent with the initial identification information indicated by the verification file.

5. The method according to claim 2 or 3, characterized in that, The method further includes: Based on the target verification information and the verification file, the target legality level of the target device is determined; Based on the target legality level of the target device, the target device is controlled to work with the work permissions corresponding to the target legality level. Different legality levels correspond to different work permissions.

6. The method according to claim 1, characterized in that, The verification file is an encrypted file, and the method further includes: Determine the validity of the verification file; If the verification file is a valid file, then the verification file is decrypted. If the verification file is successfully decrypted, the step of determining the legitimacy of the target device based on the target verification information and the verification file is executed; or, if the verification file cannot be successfully decrypted, the target device is determined to be an illegitimate device.

7. The method according to claim 1, characterized in that, Before obtaining the target verification information and verification file corresponding to the target device, the method further includes: Determine the initial identification information of the target device, wherein the initial identification information includes at least one of an initial device identifier, an initial chip identifier, and an initial software identifier; Based on the initial identification information, a verification file corresponding to the target device is generated; Write the verification file to the target device.

8. The method according to claim 7, characterized in that, The step of generating a verification file corresponding to the target device based on the initial identification information includes: Based on the initial identification information, the first verification parameter is determined; Based on the second verification parameter, a verification file corresponding to the target device is generated.

9. The method according to claim 7, characterized in that, Before writing the verification file to the target device, the method further includes: Encrypt the verification file; The step of writing the verification file to the target device includes: The encrypted verification file is written to the target device.

10. A device authentication apparatus, characterized in that, include: The device driver module is used to obtain target verification information and verification file corresponding to the target device. The target verification information is used to indicate the identification information of the target device, and the verification file is used to indicate the initial identification information of the target device when it leaves the factory. The authentication management module is used to determine the legitimacy of the target device based on the target verification information and the verification file.

11. The apparatus according to claim 10, characterized in that, The authentication management module includes a device management submodule and an authentication submodule; The device management submodule is used to receive the target verification information and the verification file obtained by the device driver module, and send an authentication request to the authentication submodule based on the target verification information and the verification file. The authentication submodule is used to verify the consistency between the target verification information and the initial identification information indicated by the verification file, obtain a first verification result, and send the first verification result to the device management submodule; The device management submodule is further configured to determine the legitimacy of the target device based on the first verification result.

12. The apparatus according to claim 11, characterized in that, The device management submodule is specifically used for: If the first verification result indicates that the target verification information and the initial identification information indicated by the verification file are consistent, the target device is determined to be a legitimate device.

13. The apparatus according to claim 12, characterized in that, The target verification information includes at least one of device identifier, chip identifier, and software identifier; the initial identifier information includes at least one of initial device identifier, initial chip identifier, and initial software identifier. The authentication submodule is specifically used to: verify the consistency between the device identifier and the initial device identifier, the chip identifier and the initial chip identifier, and the software identifier and the initial software identifier to obtain a second verification result; if the second verification result indicates that the device identifier and the initial device identifier are consistent, the chip identifier and the initial chip identifier are consistent, and the software identifier and the initial software identifier are consistent, determine that the target verification information is consistent with the initial identifier information indicated by the verification file.

14. The apparatus according to claim 12, characterized in that, The verification file also includes a first verification parameter, which is a verification parameter generated based on the initial identification information; The authentication submodule is further configured to determine a second verification parameter based on the target verification information; Verify the consistency between the second verification parameter and the first verification parameter to obtain a third verification result; if the third verification result indicates that the second verification parameter and the first verification parameter are consistent, determine that the target verification information is consistent with the initial identification information indicated by the verification file.

15. The apparatus according to claim 11, characterized in that, The device management submodule is further configured to send illegal authentication information to the device driver module when the first verification result indicates that the target verification information and the initial identification information indicated by the verification file are inconsistent. The device driver module is also configured to refuse to drive the target device to work upon receiving the illegal authentication information.

16. The apparatus according to claim 14, characterized in that, The device management submodule is also used for: Based on the second verification result and / or the third verification result, the target legality level of the target device is determined, and different legality levels correspond to different work permissions; Based on the target legality level, a target level control instruction is generated and sent to the device driver module. Different legality levels correspond to different level control instructions. The device driver module is also used to control the target device to work with the working permissions corresponding to the target legal level based on the target level control instruction.

17. The apparatus according to claim 11, characterized in that, The verification file is an encrypted file, and the authentication submodule is further used for: Determine the validity of the verification file; If the verification file is a valid file, then the verification file is decrypted. If the verification file is successfully decrypted, the legitimacy of the target device is determined based on the target verification information and the verification file; or, if the verification file cannot be successfully decrypted, the target device is determined to be an illegitimate device.

18. A device authentication apparatus, characterized in that, It includes a memory and a processor, the memory being used to store computer instructions, and the processor being used to retrieve and execute the computer instructions from the memory to implement the method as described in any one of claims 1-9.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a processor, implement the method as described in any one of claims 1-9.

20. A computer program product, characterized in that, The computer program product includes instructions that, when executed on a processor, implement the method as described in any one of claims 1-9.

Images