Industrial service ngtld identification allocation and resolution coordination method

Abstract

The application relates to the field of communication technology, in particular to an industrial service NgTLD identification allocation and resolution coordination method, which comprises the following steps: step 1: a server presets a public encryption algorithm, a public layer generates a public private key and a public public key based on the public encryption algorithm, generates a public digital certificate based on the public private key and a public signature, and the public public key is disclosed to the server; the public layer registers a private domain digital certificate based on the consent information of all private domain layers under jurisdiction; in the technical scheme provided by the application, when the NgTLD identification is resolved, it is a kind of decentralized behavior, only needs to download the corresponding public key in the public network layer or the public server, and the legality of the NgTLD identification can be verified. In practice, each receiving device only needs to update the public key information added in the server in time, so that after the NgTLD identification is obtained, whether the NgTLD identification is correct can be accurately judged, and the source and identity of the information are judged.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a collaborative method for the allocation and resolution of NgTLD identifiers for industrial services. Background Technology

[0002] The Industrial Internet Identification System is an infrastructure that assigns globally unique identifiers to physical entities (such as equipment and products) and virtual objects (such as data and algorithms). It aims to achieve full lifecycle tracking and data sharing across enterprises and platforms. Its core requirement is to solve the problem of heterogeneous interconnection of equipment through unified coding, and to support the accurate positioning and information exchange of objects in scenarios such as intelligent manufacturing and supply chain collaboration.

[0003] Current mainstream solutions include the ISO / IEC-led OID (Object Identifier) ​​tree encoding, the prefix / suffix hierarchical structure of the Handle system, and the GS1 EPC (Electronic Product Code) standard. These technologies rely on centralized registration authorities (such as CNRI for Handle and GS1 for EPC) for identifier allocation, adopt a hierarchical recursive resolution architecture (such as Handle proxy → global root server → prefix server), and implement the mapping of identifiers to network addresses through dedicated protocols (HTTP REST / DNS extensions).

[0004] Different industries / enterprises use independent identification systems (such as Handle used by factory A and EPC used by factory B), which leads to the need to maintain complex mapping tables for cross-system interaction; global recursive queries rely on a single root server (such as Handle root node located in Germany), cross-border resolution latency exceeds 200ms, and root node failure will cause regional service interruption, making it difficult to meet the millisecond-level response requirements of industrial real-time control (such as robotic arm collaboration). Summary of the Invention

[0005] The summary section of this application is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this application propose a collaborative method for industrial service NgTLD identifier allocation and resolution to address the technical problems mentioned in the background section above.

[0007] As part of this application, some embodiments of this application provide a collaborative method for industrial service NgTLD identifier allocation and resolution, including the following steps:

[0008] Step 1: The server presets a public encryption algorithm. Based on the public encryption algorithm, a public private key and a public public key are generated in the public layer. Based on the public private key and the public signature, a public digital certificate is generated. The public public key is made public to the server.

[0009] Step 2: Based on the public encryption algorithm, the private layer generates a private key and a private public key. Based on the private key and the private signature, a private digital certificate is generated. The private public key is sent to the public layer, which then publishes the private digital certificate to the server.

[0010] The public layer registers private domain digital certificates based on the consent information from all subordinate private domain layers.

[0011] Step 3: The private domain layer presets a private domain encryption algorithm. Based on the private domain encryption algorithm, the terminal device generates a device private key and a device public key. Based on the device private key and device ID, a device digital certificate is generated. The device public key is sent to the private domain layer and then published to the server by the private domain layer.

[0012] Step 4: Use the public digital certificate, private domain digital certificate, and device digital certificate as the NgTLD identifier for the device;

[0013] Step 5: Receive the NgTLD identifier of the device, and verify the public digital certificate, private digital certificate and device digital certificate in sequence using the public private key, private domain public key and device public key. If there is an error in the public digital certificate, private domain digital certificate and device digital certificate, mark it as an incorrect NgTLD identifier, otherwise mark it as a correct NgTLD identifier.

[0014] The technical solution provided in this application employs a decentralized approach to parsing NgTLD identifiers. It only requires downloading the corresponding public key from a public network layer, or a public server, to verify the legitimacy of the NgTLD identifier. In practice, each receiving device only needs to update the public key information added to the server in a timely manner to accurately determine the correctness of the NgTLD identifier after obtaining it, thereby identifying the source and identity of the information.

[0015] Furthermore, the public layer oversees multiple private domain layers, and each private domain layer oversees multiple devices. For a newly added private domain layer, the public layer requires confirmation information from the other connected private domain layers before it can generate a private domain digital certificate for the newly added private domain layer.

[0016] The technical solution provided in this application strictly controls the opening of private domain digital certificates at the intermediate level in terms of digital certificate management. Therefore, within the entire network, when forging an NgTLD identifier, it is necessary to further forge the next part of the private domain certificate based on the existing private domain digital certificate, which greatly increases the cost of forgery. In the absence of a specific method for generating private domain digital certificates, it is difficult to randomly forge a genuine NgTLD identifier using the obtained digital certificate.

[0017] Furthermore, step 2 includes the following steps:

[0018] Step 21: Private Domain Layer R i A private key E is generated randomly using a public encryption algorithm. i and private public key F i Using private public key F i The initial private domain certificate is obtained by encrypting the private domain signature, and the private domain layer R... i Private public key F i The initial private domain certificate and certificate application are sent to the public layer;

[0019] Step 22: The public layer receives the certificate request using the private public key F. i Decrypt the initial private certificate to obtain the private signature, verify the private signature, and if the verification is successful, save the private public key F. i If the verification fails, the private domain public key will be deleted and the private domain digital certificate registration will be terminated.

[0020] Step 23: The public layer combines the initial private certificate, the public signature of the public layer, and the private public key F. i The verification message is obtained by encrypting it using a public key and then sent to all subordinate private domain layers. Upon receiving the public message, each of the remaining private domain layers decrypts it using the public key and then decrypts it using its private key F. i Decrypt the initial private domain certificate, verify the public signature and the private domain signature, encrypt the confirmation information and verification information with your own private domain key to obtain the audit information, send it to the public layer, and confirm whether it passes or fails.

[0021] Step 24: The public layer decrypts the audit information using the corresponding private domain public key to obtain confirmation information. Once more than a preset percentage of all subordinate private domain layers agree, the initial private domain certificate, validity period, and private domain public key F are shared. i Encrypt using a public-private key to generate a private digital certificate, and then expose the private digital certificate to the server.

[0022] In the technical solution provided in this application, the private domain layer R iWhen applying for a private domain digital certificate, the application only needs to be submitted within the public layer. Authentication is granted only after all private domain layers under the public layer agree. Therefore, within high-level servers, information authentication is relatively free and decentralized, reducing the difficulty and increasing the efficiency of identity registration. However, within a public layer, registering a private domain digital certificate requires authentication from a sufficient number of private domain layers, ensuring the security of information throughout the server and increasing the risk of unauthorized intrusion.

[0023] Step 3 includes the following steps:

[0024] Step 31: The private domain layer presets a private domain encryption algorithm and sends the private domain encryption algorithm to the public layer, which then sends it to the server for storage.

[0025] Step 32: Based on the private domain encryption algorithm, the terminal device generates a device private key and a device public key. The device public key is sent to the private domain layer, which then publishes it to the server.

[0026] Step 33: The terminal device encrypts the device ID, private domain digital certificate, and public digital certificate using the device private key to generate a device digital certificate.

[0027] In the technical solution provided in this application, the terminal device uses a private domain encryption algorithm set by the private domain layer itself when generating the identifier. This can greatly increase the diversity of encryption algorithms within the entire server. Although the complexity of encryption may not necessarily increase, the encryption methods of information become more diverse, reducing the possibility of unauthorized persons obtaining information and then comparing the encrypted and decrypted information to decrypt the encryption algorithm, thereby further increasing information security.

[0028] Private domain digital certificates are a crucial piece of data. Public digital certificates at the public layer are relatively easy to obtain and forge, and the losses caused by forgery are minimal. However, digital certificates for even the smallest terminal devices are extremely easy to forge on a large scale within the network system. Therefore, strict management of private domain digital certificates is necessary. However, if private domain digital certificates are frequently changed, multiple requests are required, leading to frequent authentication of private domain certificates at each private layer within the public layer. This increases the frequency of authentication information theft and, consequently, the risk of information leakage. Based on this, this application provides the following technical solution:

[0029] Furthermore, step 5 includes the following steps:

[0030] Step 51: Receive the NgTLD identifier, decrypt the public digital certificate with the public key, verify the public signature, locate the server to which the NgTLD identifier belongs, and if the verification fails, the NgTLD identifier cannot be recognized.

[0031] Step 52: Decrypt the private digital certificate using the public key to obtain the initial private certificate, validity period, and private public key F. i Using private public key F i Decrypt the initial private domain certificate to obtain the private domain signature, verify the private domain signature, and locate the NgTLD identifier of the lower-level node; if the verification fails, the NgTLD identifier cannot be recognized.

[0032] Step 53: Decrypt the device digital certificate with the device public key to obtain the device ID, private digital certificate and public digital certificate. Verify the decrypted private digital certificate and public digital certificate to locate the network location of the NgTLD identifier. If the verification fails, the NgTLD identifier cannot be recognized.

[0033] Furthermore, the method for generating a private signature includes the following steps:

[0034] S1: The private domain layer predefines an image set Q, Q={q1, q2, ... q} n …q n0}, where n represents the index of the image in the image set, n0 represents the total number of images in the image set, and q n Let n represent the nth image, where each image in the image set Q is used as the source image for the signature;

[0035] S2: Obtain the initial private domain certificates issued in the history of the private domain layer itself, randomly select any two initial private domain certificates, and extract the signature source image q from them. g q h ;

[0036] S3: A preset random function is used to generate extraction information U based on the filtered information u, and two signature source images q are extracted from the image set Q based on the extraction information. g `、q h `;

[0037] S4: change q g q h q g `、q h The system is divided into four regions, and then four regions are randomly selected and combined to form a private domain signature.

[0038] In the technical solution provided in this application, the private domain digital certificate has an expiration date, so there are no private domain digital certificates that can be used for a long time. Each time a private domain digital certificate is generated, it needs to be encrypted using a private domain signature. And each time the private domain signature is encrypted, it is different. Therefore, the risk of the initial private domain certificate being cracked is reduced. At the same time, the generation of the private domain signature is not random; it uses four signature source images from different sources, randomly spliced ​​according to a four-eighths division. Therefore, the private domain signature still retains the information used for identity authentication. Thus, with the identity information remaining valid for a long time, random initial private domain certificates can be continuously generated.

[0039] Further filtering information includes the validity period of the private domain digital certificate used to generate it.

[0040] When verifying the authenticity of the signature source image, publicly disclosing the specific form of the signature source image (private domain signature) across the entire network would greatly increase information security risks and reduce the difficulty for unauthorized individuals to forge NgTLD identifiers. Based on this, this application provides the following technical solution:

[0041] Furthermore, when verifying the private domain signature, the positional offset and frequency energy changes of SIFT feature points in the signature source image are verified.

[0042] In the technical solution provided in this application, the position offset and frequency energy change of SIFT feature points are used as verification points for private domain signatures. This can accurately identify whether the target image is an accurate private domain signature even when the signature source image contains a large amount of noise information. Furthermore, it can accurately determine the authenticity of the signature source image even without prior communication of the specific information content of the signature source image.

[0043] Furthermore, feature point extraction includes the following steps:

[0044] SO1: Perform scale-space extremum detection on the signature source image I(x,y) to obtain candidate feature points;

[0045] The scale space L(x, y, σ) is defined as: L(x, y, σ) = G(x, y, σ) × I(x, y);

[0046] Where G(x, y, σ) is a Gaussian function;

[0047] ;

[0048] SO2: Feature points are described using gradient magnitude m and direction θ;

[0049] ;

[0050] ;

[0051] Where x and y are the x and y coordinates of the pixel, respectively, σ is the standard deviation of the Gaussian function, m(x,y) represents the gradient magnitude at position (x,y), and L refers to the image after Gaussian blurring of image I at different scales.

[0052] Furthermore, the frequency domain information matrix of the signature source image:

[0053] ;

[0054] Where g(b) and g(h) are normalization factors, b and h are the horizontal and vertical coordinates in the frequency coefficient matrix, respectively, C(b, h) represents the frequency domain information at (x, y) in the signature source image, and M and N are the number of rows and columns of pixels in the original image, respectively.

[0055] Furthermore, the encryption process of public encryption algorithms is as follows:

[0056] T1: Generate a b*b initial key matrix;

[0057] T2: Copy the first 4 words of the initial key matrix to the first 4 words of the extended key array, i.e., W[0], W[1], W[2], W[3];

[0058] T3: Expand the initial key matrix based on the following scheme for i = 4 to 43: If i is not a multiple of 4, then:

[0059] W[i] = W[i-4] ⊕ W[i-1]

[0060] If i is a multiple of 4, then:

[0061] W[i]=W[i-4]⊕T(W[i-1])

[0062] Here, ⊕ represents the XOR operation, and T is a complex function that includes three steps: word looping, byte substitution, and round constant XOR.

[0063] Word loop: Circularly shift the 4 bytes of W[i-1] to the left by 1 byte;

[0064] Byte substitution: Use the S-box to perform byte substitution on the result of word loop;

[0065] Round constant XOR: XOR the results of the first two steps with the round constant Rcon[j], where j is the current round number (counting from 1).

[0066] The round constant Rcon[j] is a fixed sequence used to increase the complexity of the key in each round;

[0067] T4: Extract one 4×4 key from each round as an element in the key matrix until the key matrix is ​​generated;

[0068] T5: Use the RSA algorithm to generate a public key and a private key pair, encrypt the public key with a key matrix, and generate a key pair.

[0069] The technical solution provided in this application combines asymmetric and symmetric encryption, which greatly increases the security of information encryption while reducing the difficulty of information decryption. Without the private key matrix, unauthorized attackers are virtually unable to crack the actual content of the public key. Furthermore, regularly updating the private key matrix significantly enhances information security. Attached Figure Description

[0070] Figure 1 A flowchart of a collaborative method for NgTLD identifier allocation and resolution for industrial services. Detailed Implementation

[0071] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments. The same reference numerals in the accompanying drawings represent the same components. It should be noted that the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the described embodiments of this application without creative effort are within the scope of protection of this application.

[0072] Compared to the embodiments shown in the accompanying drawings, feasible embodiments within the scope of this application may have fewer components, other components not shown in the drawings, different components, differently arranged components, or components with different connections, etc. Furthermore, two or more components in the drawings may be implemented in a single component, or a single component shown in the drawings may be implemented as multiple separate components.

[0073] Unless otherwise defined, the technical or scientific terms used herein shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains. The terms “second” and similar words used in this specification and claims do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, the terms “a” or “an” and similar words do not necessarily indicate a quantity limitation. Terms such as “upper” and “lower” are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0074] The collaborative method for NgTLD identifier allocation and resolution in industrial services includes the following steps:

[0075] Step 1: The server presets a public encryption algorithm. Based on the public encryption algorithm, a public private key and a public public key are generated in the public layer. Based on the public private key and the public signature, a public digital certificate is generated, and the public public key is made public to the server.

[0076] At the network layer, there are multiple servers, each server overseeing multiple public layers, each public layer overseeing multiple private layers, and each private layer overseeing multiple devices. The public layers are industry domains, the private layers are factory domains, and the devices are freely registered within the factory. Therefore, in the entire IoT system, the public layers remain unchanged, private layers need the consent of the entire industry to enter the public layer, and devices can be randomly registered and generated within the private layers.

[0077] Thus, for NgTLD identifiers within the entire Internet of Things (IoT), as long as the private domain layer itself does not generate two identical device codes, it can randomly expand the NgTLD identifiers required by the device. When adding or removing NgTLD identifiers, only the private domain layer needs to manage it. When verifying NgTLD identifiers, participants only need to receive relevant information for verification. This reduces the problem of needing to make multiple queries when verifying NgTLD identifiers.

[0078] Step 2: Based on the public encryption algorithm, the private layer generates a private key and a private public key. Based on the private key and the private signature, a private digital certificate is generated. The private public key is sent to the public layer, which then publishes the private digital certificate to the server.

[0079] The public layer registers private domain digital certificates based on the consent information of all its subordinate private domain layers.

[0080] Step 2 includes the following steps:

[0081] Step 21: Private Domain Layer R i A private key E is generated randomly using a public encryption algorithm. i and private public key F i Using private public key F i The initial private domain certificate is obtained by encrypting the private domain signature, and the private domain layer R... i Private public key F i The initial private domain certificate and certificate application are sent to the public layer;

[0082] Step 22: The public layer receives the certificate request using the private public key F. i Decrypt the initial private certificate to obtain the private signature, verify the private signature, and if the verification is successful, save the private public key F. i If the verification fails, the private domain public key will be deleted and the private domain digital certificate registration will be terminated.

[0083] Step 23: The public layer combines the initial private certificate, the public signature of the public layer, and the private public key F.i The verification message is obtained by encrypting it using a public key and then sent to all subordinate private domain layers. Upon receiving the public message, each of the remaining private domain layers decrypts it using the public key and then decrypts it using its private key F. i Decrypt the initial private domain certificate, verify the public signature and the private domain signature, encrypt the confirmation information and verification information with your own private domain key to obtain the audit information, send it to the public layer, and confirm whether it passes or fails.

[0084] Step 24: The public layer decrypts the audit information using the corresponding private domain public key to obtain confirmation information. Once more than a preset percentage of all subordinate private domain layers agree, the initial private domain certificate, validity period, and private domain public key F are shared. i Encrypt using a public-private key to generate a private digital certificate, and then expose the private digital certificate to the server.

[0085] In step 2, the private domain digital certificate is not generated by the private domain layer itself, but requires authorization from other private domain layers in the public layer to be generated. Therefore, it ensures a certain degree of oversight of the issuance of NgTLD identifiers, and can determine the location of NgTLD identifiers by utilizing the location of the private domain layer.

[0086] Step 3: The private domain layer presets a private domain encryption algorithm. Based on the private domain encryption algorithm, the terminal device generates a device private key and a device public key. Based on the device private key and device ID, a device digital certificate is generated. The device public key is sent to the private domain layer and then published to the server by the private domain layer.

[0087] Step 3 includes the following steps:

[0088] Step 31: The private domain layer presets a private domain encryption algorithm and sends the private domain encryption algorithm to the public layer, which then sends it to the server for storage.

[0089] Step 32: Based on the private domain encryption algorithm, the terminal device generates a device private key and a device public key. The device public key is sent to the private domain layer, which then publishes it to the server.

[0090] Step 33: The terminal device encrypts the device ID, private domain digital certificate, and public digital certificate using the device private key to generate a device digital certificate.

[0091] Step 4: Use the public digital certificate, private domain digital certificate, and device digital certificate as the NgTLD identifier for the device;

[0092] Step 5: Receive the NgTLD identifier of the device, and verify the public digital certificate, private digital certificate and device digital certificate in sequence using the public private key, private domain public key and device public key. If there is an error in the public digital certificate, private domain digital certificate and device digital certificate, mark it as an incorrect NgTLD identifier, otherwise mark it as a correct NgTLD identifier.

[0093] Step 5 includes the following steps:

[0094] Step 51: Receive the NgTLD identifier, decrypt the public digital certificate with the public key, verify the public signature, locate the server to which the NgTLD identifier belongs, and if the verification fails, the NgTLD identifier cannot be recognized.

[0095] Step 52: Decrypt the private digital certificate using the public key to obtain the initial private certificate, validity period, and private public key F. i Using private public key F i Decrypt the initial private domain certificate to obtain the private domain signature, verify the private domain signature, and locate the NgTLD identifier of the lower-level node; if the verification fails, the NgTLD identifier cannot be recognized.

[0096] Step 53: Decrypt the device digital certificate with the device public key to obtain the device ID, private digital certificate and public digital certificate. Verify the decrypted private digital certificate and public digital certificate to locate the network location of the NgTLD identifier. If the verification fails, the NgTLD identifier cannot be recognized.

[0097] Example 2: Based on Example 1, Example 2 provides a method for generating and verifying private domain signatures. A private domain signature is essentially an image signature used by the private domain layer to identify itself.

[0098] The process of generating a private signature includes the following steps:

[0099] S1: The private domain layer predefines an image set Q, Q={q1, q2, ... q} n …q n0}, where n represents the index of the image in the image set, n0 represents the total number of images in the image set, and q n Let represent the nth image, where each image in the image set Q is used as the source image for the signature.

[0100] The image contains the official seal of the private domain layer, or other images used to identify the identity. In practice, to increase the resistance of private domain signatures to being cut, information from any 1 / 4 of the image can be used to confirm the identity of the private domain layer.

[0101] S2: Obtain the initial private domain certificates issued in the history of the private domain layer itself, randomly select any two initial private domain certificates, and extract the signature source image q from them. g q h ;

[0102] S3: A preset random function is used to generate extraction information U based on the filtered information u, and two signature source images q are extracted from the image set Q based on the extraction information. g `、q h `;

[0103] The filter information is the validity period of the private domain digital certificate used for generation. Specifically, it includes the initial timestamp T of the validity period. s and final timestamp T d Input a random function, and transform it using timestamp numerical features (e.g., taking T). s The last three digits and T d The modulo operation of the sum of the last three digits generates two index values ​​g' and h', ensuring that 1 ≤ g', h' ≤ n0 and g' ≠ h'. Finally, the extracted information U = (g', h') is output, and the corresponding signature source image q is extracted from the image set Q based on this information. g `、q h `.

[0104] S4: change q g q h q g `、q h The system is divided into four regions, and then four regions are randomly selected and combined to form a private domain signature.

[0105] Information from any 1 / 4 of the image can be used to confirm the identity of the private domain layer. Therefore, no matter how these 4 areas are combined, both the randomness and recognizability of the private domain signature can be guaranteed.

[0106] Furthermore, when verifying the private domain signature, the positional offset and frequency energy changes of SIFT feature points in the signature source image are verified.

[0107] When verifying private domain signatures, the ability to identify every region in the signature source image makes it difficult to recognize information from different parts of the image. If the images are too similar, it becomes difficult to extract information. Recording each part separately, however, increases the difficulty of subsequent image recognition. Therefore, this application uses the positional offset and frequency energy changes of SIFT feature points as recognition information.

[0108] Specifically, for an image bearing an official seal, although the rotation angle of the seal differs in each image, the relative positions of the internal feature points within the seal pattern remain unchanged, and the corresponding energy information also remains constant. This application is based on this principle for private domain image information recognition.

[0109] SO1: Perform scale-space extremum detection on the signature source image I(x,y) to obtain candidate feature points;

[0110] The scale space L(x, y, σ) is defined as: L(x, y, σ) = G(x, y, σ) × I(x, y);

[0111] Where G(x, y, σ) is a Gaussian function;

[0112] ;

[0113] SO2: Feature points are described using gradient magnitude m and direction θ;

[0114] ;

[0115] ;

[0116] Where x and y are the x and y coordinates of the pixel, respectively, σ is the standard deviation of the Gaussian function, m(x,y) represents the gradient magnitude at position (x,y), and L refers to the image after Gaussian blurring of image I at different scales.

[0117] Frequency domain information matrix of the signature source image:

[0118] ;

[0119] Where g(b) and g(h) are normalization factors, b and h are the horizontal and vertical coordinates in the frequency coefficient matrix, respectively, C(b, h) represents the frequency domain information at (x, y) in the signature source image, and M and N are the number of rows and columns of pixels in the original image, respectively.

[0120] After extracting the feature points, the positions between the feature points are extracted and compared with the standard information. The correctness of the private domain signature is determined based on whether the offset of the relative positions exceeds a preset threshold.

[0121] After extracting the frequency domain information matrix, it is compared with the standard information, and the correctness of the private domain signature is determined by whether the pre-defined similarity exceeds a preset threshold.

[0122] Example 3: Example 3 provides an encryption method based on Example 2:

[0123] The encryption process of public encryption algorithms is as follows:

[0124] T1: Generate an initial key matrix of size b*b.

[0125] T2: Copy the first 4 words of the initial key matrix to the first 4 words of the extended key array, i.e. W[0], W[1], W[2], W[3].

[0126] T3: Expand the initial key matrix based on the following scheme for i = 4 to 43: If i is not a multiple of 4, then:

[0127] W[i] = W[i-4] ⊕ W[i-1]

[0128] If i is a multiple of 4, then:

[0129] W[i]=W[i-4]⊕T(W[i-1])

[0130] Here, ⊕ represents the XOR operation, and T is a complex function that includes three steps: word looping, byte substitution, and round constant XOR.

[0131] Word loop: Circularly shift the 4 bytes of W[i-1] to the left by 1 byte;

[0132] Byte substitution: Use the S-box to perform byte substitution on the result of word loop;

[0133] Round constant XOR: XOR the results of the first two steps with the round constant Rcon[j], where j is the current round number (counting from 1).

[0134] The round constant Rcon[j] is a fixed sequence used to increase the complexity of the key in each round;

[0135] T4: Extract one 4×4 key from each round as an element in the key matrix until the key matrix is ​​generated;

[0136] T5: Use the RSA algorithm to generate a public key and a private key pair, encrypt the public key with a key matrix, and generate a key pair.

[0137] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A collaborative method for NgTLD identifier allocation and resolution in industrial services, characterized in that, include: Step 1: The server presets a public encryption algorithm. Based on the public encryption algorithm, a public private key and a public public key are generated in the public layer. Based on the public private key and the public signature, a public digital certificate is generated. The public public key is made public to the server. Step 2: Based on the public encryption algorithm, the private layer generates a private key and a private public key. Based on the private key and the private signature, a private digital certificate is generated. The private public key is sent to the public layer, which then publishes the private digital certificate to the server. The public layer registers private domain digital certificates based on the consent information from all subordinate private domain layers. Step 3: The private domain layer presets a private domain encryption algorithm. Based on the private domain encryption algorithm, the terminal device generates a device private key and a device public key. Based on the device private key and device ID, a device digital certificate is generated. The device public key is sent to the private domain layer and then published to the server by the private domain layer. Step 4: Use the public digital certificate, private domain digital certificate, and device digital certificate as the NgTLD identifier for the device; Step 5: Receive the NgTLD identifier, and verify the public digital certificate, private digital certificate, and device digital certificate in sequence using the public key, private key, and device digital certificate. If there is an error in any of the public digital certificate, private digital certificate, and device digital certificate, mark it as an incorrect NgTLD identifier; otherwise, mark it as a correct NgTLD identifier. Step 2 includes the following steps: Step 21: Private Domain Layer R i A private key E is generated randomly using a public encryption algorithm. i and private public key F i Using private public key F i The initial private domain certificate is obtained by encrypting the private domain signature, and the private domain layer R... i Private public key F i The initial private domain certificate and certificate application are sent to the public layer; Step 22: The public layer receives the certificate request using the private public key F. i Decrypt the initial private certificate to obtain the private signature, verify the private signature, and if the verification is successful, save the private public key F. i If the verification fails, the private domain public key will be deleted and the private domain digital certificate registration will be terminated. Step 23: The public layer combines the initial private certificate, the public signature of the public layer, and the private public key F. i The verification message is obtained by encrypting it using a public key and then sent to all subordinate private domain layers. Upon receiving the public message, each of the remaining private domain layers decrypts it using the public key and then decrypts it using its private key F. i Decrypt the initial private domain certificate, verify the public signature and the private domain signature, encrypt the confirmation information and verification information with your own private domain key to obtain the audit information, send it to the public layer, and confirm whether it passes or fails. Step 24: The public layer decrypts the audit information using the corresponding private domain public key to obtain confirmation information. Once more than a preset percentage of all subordinate private domain layers agree, the initial private domain certificate, validity period, and private domain public key F are shared. i Encrypt using a public-private key to generate a private digital certificate, and then expose the private digital certificate to the server. Step 5 includes the following steps: Step 51: Receive the NgTLD identifier, decrypt the public digital certificate with the public key, verify the public signature, locate the server to which the NgTLD identifier belongs, and if the verification fails, the NgTLD identifier cannot be recognized. Step 52: Decrypt the private digital certificate using the public key to obtain the initial private certificate, validity period, and private public key F. i Using private public key F i Decrypt the initial private domain certificate to obtain the private domain signature, verify the private domain signature, and locate the NgTLD identifier of the lower-level node; if the verification fails, the NgTLD identifier cannot be recognized. Step 53: Decrypt the device digital certificate with the device public key to obtain the device ID, private digital certificate and public digital certificate. Verify the decrypted private digital certificate and public digital certificate to locate the network location of the NgTLD identifier. If the verification fails, the NgTLD identifier cannot be recognized.

2. The collaborative method for industrial service NgTLD identifier allocation and resolution according to claim 1, characterized in that, Step 3 includes the following steps: Step 31: The private domain layer presets a private domain encryption algorithm and sends the private domain encryption algorithm to the public layer, which then sends it to the server for storage. Step 32: Based on the private domain encryption algorithm, the terminal device generates a device private key and a device public key. The device public key is sent to the private domain layer, which then publishes it to the server. Step 33: The terminal device encrypts the device ID, private digital certificate, and public digital certificate using the device private key to generate a device digital certificate.

3. The collaborative method for industrial service NgTLD identifier allocation and resolution according to claim 1, characterized in that, The process of generating a private signature includes the following steps: S1: The private domain layer predefines an image set Q, Q={q1, q2, ... q} n …q n0 }, where n represents the index of the image in the image set, n0 represents the total number of images in the image set, and q n Let represent the nth image, where each image in image set Q is used as the source image for the signature; S2: Obtain the initial private domain certificates issued in the history of the private domain layer itself, randomly select any two initial private domain certificates, and extract the signature source image q from them. g q h ; S3: A preset random function is used to generate extraction information U based on the filtered information u, and two signature source images q are extracted from the image set Q based on the extraction information. g `、q h `; S4: change q g q h q g `、q h The system is divided into four regions, and then four regions are randomly selected and combined to form a private domain signature.

4. The collaborative method for industrial service NgTLD identifier allocation and resolution according to claim 3, characterized in that, The filter information is the validity period of the private domain digital certificate used to generate it.

5. The collaborative method for industrial service NgTLD identifier allocation and resolution according to claim 1, characterized in that, When verifying a private domain signature, verify the positional offset and frequency energy changes of SIFT feature points in the signature source image.

6. The collaborative method for industrial service NgTLD identifier allocation and resolution according to claim 5, characterized in that, SO1: Perform scale-space extremum detection on the signature source image I(x,y) to obtain candidate feature points; The scale space L(x, y, σ) is defined as: L(x, y, σ) = G(x, y, σ) × I(x, y); Where G(x, y, σ) is a Gaussian function; ； SO2: Feature points are described using gradient magnitude m and direction θ; ； ； Where x and y are the x and y coordinates of the pixel, respectively, σ is the standard deviation of the Gaussian function, m(x,y) represents the gradient magnitude at position (x,y), and L refers to the image after Gaussian blurring of image I at different scales.

7. The collaborative method for industrial service NgTLD identifier allocation and resolution according to claim 5, characterized in that, Frequency domain information matrix of the signature source image: ; Where g(b) and g(h) are normalization factors, b and h are the horizontal and vertical coordinates in the frequency coefficient matrix, respectively, C(b, h) represents the frequency domain information at (x, y) in the signature source image, and M and N are the number of rows and columns of pixels in the original image, respectively.

8. The collaborative method for industrial service NgTLD identifier allocation and resolution according to claim 1, characterized in that, The encryption process of public encryption algorithms is as follows: T1: Generate a b*b initial key matrix; T2: Copy the first 4 words of the initial key matrix to the first 4 words of the extended key array, i.e., W[0], W[1], W[2], W[3]; T3: Expand the initial key matrix based on the following scheme for i = 4 to 43: If i is not a multiple of 4, then: W[i] = W[i-4] ⊕ W[i-1] If i is a multiple of 4, then: W[i]=W[i-4]⊕T(W[i-1]) Here, ⊕ represents the XOR operation, and T is a complex function that includes three steps: word looping, byte substitution, and round constant XOR. Word loop: Circularly shift the 4 bytes of W[i-1] to the left by 1 byte; Byte substitution: Use the S-box to perform byte substitution on the result of word loop; Round constant XOR: XOR the results of the first two steps with the round constant Rcon[j], where j is the current round number (counting from 1). The round constant Rcon[j] is a fixed sequence used to increase the complexity of the key in each round; T4: Extract one 4×4 key from each round as an element in the key matrix until the key matrix is ​​generated; T5: Use the RSA algorithm to generate a public key and a private key pair, encrypt the public key with a key matrix, and generate a key pair.

Images