A terminal network device zero-contact configuration method based on an Internet of Things card Ukey

Abstract

The application discloses a kind of based on the terminal network equipment zero contact configuration method of Ukey, comprising: by the initial index file and authentication algorithm of Ukey, Ukey and cloud controller carry out two-way authentication;Ukey and cloud controller two-way authentication success, SSL tunnel is established between Ukey and cloud controller;By the initial index file and authentication algorithm of Ukey, Internet of Things Ukey and equipment carry out two-way authentication;Internet of Things Ukey and the equipment two-way authentication success, equipment requests the API of cloud controller's management by SSL tunnel established between Ukey and cloud controller, obtains management configuration information;The equipment automatically loads the management configuration information and carries out initial. The application realizes that Ukey is automatically acquired according to equipment information to cloud controller equipment management configuration.

Description

Technical Field

[0001] This application relates to the fields of IT and software development technology, and in particular to a zero-contact configuration method for terminal network devices based on IoT SIM card Ukey. Background Technology

[0002] Cloud networking is a new type of information infrastructure that uses cloud providers to connect network resources. The cloud is a centralized third-party resource, and is uniformly managed by a cloud-based control platform. Cloud networking establishes a network channel connecting the cloud, edge, and endpoints. Cloud resources are logically isolated by a Virtual Private Cloud (VPC) within the cloud, and the enterprise backbone is built using network technologies such as leased lines, SD-WAN, and VPN. It also supports edge devices and branch offices to access the backbone network and access cloud resources through terminal network devices such as CPE boxes and VPN clients.

[0003] Apart from Cloud Private Cloud (VPC), enterprise backbone networks and edge networks are interconnected via secure tunnels built over a wide area network (WAN), providing stable, low-latency, low-jitter, and low-packet-loss secure links. Taking an SD-WAN backbone network as an example, it typically consists of a controller, the SD-WAN backbone network itself, and CPE devices. The CPE device, as the terminal equipment of the SD-WAN network, provides edge access capabilities for branch nodes, allowing branch offices such as chain stores, gas stations, and unmanned highway toll booths to directly connect to the dedicated SD-WAN backbone network. This excludes leased-line backbone networks within the enterprise backbone network.

[0004] However, terminal network devices are often deployed at the edge of enterprises or in branch offices. For network device commissioning, online configuration and other operations, the number of deployed devices is large, the geographical location is far, and the cost of technical personnel going to the site to perform operations is high. Summary of the Invention

[0005] This application aims to at least partially address one of the technical problems in the related art. To this end, one objective of this application is to propose a zero-contact configuration method, system, electronic device, and readable storage medium for terminal network devices based on an IoT SIM card (Ukey), achieving secure device connection to a cloud controller without requiring a built-in IoT SIM card in the terminal network device.

[0006] The first aspect disclosed in this application provides a zero-contact configuration method for terminal network devices based on an IoT SIM card (Ukey), the method comprising:

[0007] The IoT Ukey and the cloud controller perform two-way authentication through the initial index file and authentication algorithm of the IoT Ukey.

[0008] When the IoT Ukey and the cloud controller successfully complete two-way authentication, an SSL tunnel is established between the IoT Ukey and the cloud controller.

[0009] The IoT Ukey and the device perform two-way authentication through the initial index file and authentication algorithm of the IoT Ukey;

[0010] After successful two-way authentication between the IoT Ukey and the device, the device requests the management API of the cloud controller through the SSL tunnel established between the IoT Ukey and the cloud controller to obtain management configuration information.

[0011] The device automatically loads the management configuration information and initiates operation.

[0012] The IoT Ukey refers to the Ukey with a built-in IoT card.

[0013] The initial index file of the IoT Ukey includes:

[0014] Index file: The name must be USB_AR.ini or USB_ar.ini, and the content contains the serial number information of the IoT Ukey and the network card ismi;

[0015] Public key: The public key for accessing the cloud controller API, ctrl_pub.pub;

[0016] SSL Certificate: Used to create an SSL tunnel between the IoT Ukey and the cloud controller;

[0017] Status file: The file status.hash records the current status of the IoT Ukey. The content is a hash, and different hashes correspond to different statuses.

[0018] The file status.hash, which records the current IoT Ukey status, contains a hash, and different hashes correspond to different statuses, including:

[0019] The hash generated by authentication algorithm 1 is the device hash matched by the IoT Ukey. The hash allows the device to determine whether the IoT Ukey has recognized the device. Only after confirmation of recognition will subsequent processes proceed.

[0020] The hash generated by authentication algorithm 2 indicates that access to the cloud controller failed or the cloud controller returned an error. The cloud controller administrator needs to investigate the cause of the error.

[0021] The steps for establishing an SSL tunnel between the IoT Ukey and the cloud controller after successful two-way authentication include:

[0022] The IoT Ukey uses its own SN and the hash_key calculated by ctrl_pub.pub as parameters to request the cloud controller's API for management.

[0023] The cloud controller receives the cloud controller management API request, verifies whether the SN and hash_key are corresponding, and if the SN and hash_key are corresponding, it returns a token1 to the IoT Ukey.

[0024] The IoT Ukey receives the returned token1, calculates token2 using the authentication algorithm, and sends the SN and token2 again to request the cloud controller to manage the API.

[0025] The cloud controller receives the SN and token2. Based on the ability of token2 to authenticate the IoT Ukey client, it verifies whether the SN has been registered. If the SN is valid, it returns authentication success and token3 to the IoT Ukey.

[0026] Upon receiving the successful authentication and token3, the IoT Ukey verifies the token3 using the authentication algorithm, confirming that the cloud controller is a legitimate server, and then begins establishing an SSL tunnel with the cloud controller.

[0027] After the IoT Ukey establishes an SSL tunnel with the cloud controller, it can access the cloud controller interface.

[0028] The steps for two-way authentication between the IoT Ukey and the network device include:

[0029] After the IoT Ukey is inserted into the device, the device can see whether the initial index file USB_AR.ini exists through the USB hook;

[0030] If the initial index file exists, the device retrieves the IoT Ukey information from the initial index file and writes the device information to device_info.ini;

[0031] The IoT Ukey uses the current device_info.ini file and its own IoT Ukey information as parameters to request the cloud controller to verify the legality of the device information;

[0032] After verifying the legitimacy of the network device, calculate hash1 of authentication algorithm 1;

[0033] Hash1 is written to the status.hash file;

[0034] Network devices use authentication algorithm 1 to calculate hash2 using Ukey information and their own information;

[0035] The network device polls the status.hash file. If it finds that hash1 in the status.hash file is the same as the calculated hash2, the network device completes the authentication of the IoT Ukey and uses authentication algorithm 1 to calculate hash3 based on hash1 and writes it into the status.hash file.

[0036] After receiving the hash3, the IoT Ukey requests the cloud controller to verify the correctness of the hash3.

[0037] After verification, the IoT Ukey completes the authentication of the device's legitimacy.

[0038] The steps for the device to automatically load the network configuration information and perform initial setup include:

[0039] An SSL tunnel was successfully established between the IoT Ukey and the cloud controller, and the IoT Ukey and the device successfully completed two-way authentication.

[0040] The device requests and downloads the management API of the cloud controller via an SSL tunnel;

[0041] The cloud controller verifies the legality of device information;

[0042] Once the device information is verified to be valid, the cloud controller returns the management configuration information to the device.

[0043] The device automatically loads the configuration information and initiates operation.

[0044] The second aspect disclosed in this application provides a zero-contact configuration system for terminal network devices based on an IoT SIM card Ukey, the system comprising:

[0045] The IoT Ukey and cloud controller two-way authentication module is used to perform two-way authentication between the IoT Ukey and the cloud controller through the IoT Ukey's initial index file and authentication algorithm;

[0046] An SSL tunnel module is established to enable the establishment of an SSL tunnel between the IoT Ukey and the cloud controller after successful two-way authentication.

[0047] The IoT Ukey and device two-way authentication module is used to perform two-way authentication between the IoT Ukey and the device through the initial index file of the IoT Ukey and the authentication algorithm;

[0048] The module for obtaining management configuration information is used when the IoT Ukey and the device successfully complete two-way authentication. The device requests the management API of the cloud controller through the SSL tunnel established between the IoT Ukey and the cloud controller to obtain management configuration information.

[0049] The initialization module is used for the device to automatically load the management configuration information and perform initialization.

[0050] The third aspect disclosed in this application is an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps in a zero-contact configuration method for a terminal network device based on an IoT SIM card Ukey.

[0051] The fourth aspect disclosed in this application is a readable storage medium storing a computer program adapted for loading by a processor to execute the steps in the described zero-contact configuration method for a terminal network device based on an IoT SIM card Ukey.

[0052] Compared with existing technologies, the zero-contact configuration method for terminal network devices based on IoT SIM card Ukey proposed in this application has the following advantages:

[0053] For existing zero-contact deployment solutions, the IoT Ukey, as a reusable IoT card device, can achieve secure device connection to the cloud controller without the need for an IoT card to be built into the terminal network device. Moreover, it requires no technical skills from the setup personnel, does not require the complicated traditional Ukey creation process, and does not require connection devices such as mobile phones or computers. They only need to insert the IoT Ukey and hand it over to the network administrator of the remote cloud controller for operation.

[0054] This application primarily addresses the issue of zero-contact online deployment for terminal devices. It addresses the limitation of existing technologies that allow devices to communicate with cloud controllers without requiring a built-in wireless network card. Instead, it utilizes an IoT Ukey to transmit device configuration information and leverages the cloud controller's configuration API. This design incorporates a Ukey with a built-in IoT card, enabling the IoT Ukey to automatically obtain device management configurations from the cloud controller and perform device setup.

[0055] The IoT Ukey and devices are mutually authenticated by the cloud management platform. The network-connected IoT Ukey enables zero-contact configuration of terminal network devices. One IoT Ukey can configure multiple terminal network devices. The cloud controller can access devices and troubleshoot problems through the temporary network channel built by the IoT Ukey. Attached Figure Description

[0056] Figure 1This is a schematic flowchart of a zero-contact configuration method for terminal network devices based on an IoT SIM card Ukey, provided in one embodiment of this application.

[0057] Figure 2 This is a schematic diagram of the two-way authentication process between the IoT Ukey and the cloud controller provided in one embodiment of this application;

[0058] Figure 3 This is a schematic diagram of the two-way authentication process between the IoT Ukey and the device provided in one embodiment of this application;

[0059] Figure 4 This is a schematic diagram of the process for opening up and activating services using the management information obtained through the IoT Ukey, provided in one embodiment of this application.

[0060] Figure 5 This is a schematic diagram of a zero-contact configuration system for terminal network devices based on an IoT SIM card Ukey, provided in one embodiment of this application;

[0061] Figure 6 This is a schematic diagram of an electronic device structure provided in one embodiment of this application;

[0062] Figure 7 This is a schematic diagram of a computer-readable storage medium structure provided in one embodiment of this application. Detailed Implementation

[0063] To better understand this application, various aspects of this application will be described in more detail with reference to the accompanying drawings. It should be understood that these detailed descriptions are merely illustrative of exemplary embodiments of this application and are not intended to limit the scope of this application in any way. Throughout the specification, the same reference numerals refer to the same elements. The expression "and / or" includes any and all combinations of one or more of the associated listed items.

[0064] In the accompanying drawings, the size, dimensions, and shapes of the elements have been slightly adjusted for ease of illustration. The drawings are for illustrative purposes only and are not strictly to scale. As used herein, the terms “approximately,” “about,” and similar terms are used to indicate approximation, not degree, and are intended to illustrate inherent deviations in measured or calculated values ​​that will be recognized by one of ordinary skill in the art. Furthermore, the order in which the steps are described in this application does not necessarily indicate the order in which these steps occur in actual operation, unless otherwise expressly defined or deduced from the context.

[0065] It should also be understood that expressions such as "comprising," "including," "having," "containing," and / or "comprising" are open-ended rather than closed-ended expressions in this specification, indicating the presence of the stated features, elements, and / or components, but not excluding the presence of one or more other features, elements, components, and / or combinations thereof. Furthermore, when expressions such as "at least one of..." appear after a list of listed features, they modify the entire list of features, not just individual elements in the list. Additionally, when describing embodiments of this application, the word "may" is used to mean "one or more embodiments of this application." And the term "exemplary" is intended to refer to examples or illustrations.

[0066] Unless otherwise specified, all terms used herein (including engineering and technical terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that, unless expressly stated herein, terms defined in common dictionaries shall be interpreted as having the meaning consistent with their meaning in the context of the relevant art, and not as having an idealized or overly formalized meaning.

[0067] It should be noted that, where there is no conflict, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0068] Example 1

[0069] Figure 1 This application provides a flowchart illustrating a zero-contact configuration method for terminal network devices based on an IoT SIM card Ukey, as shown in one embodiment. Figure 1 As shown, a zero-contact configuration method for terminal network devices based on IoT SIM card Ukey includes:

[0070] The IoT Ukey and cloud controller perform two-way authentication through the Ukey's initial index file and authentication algorithm. The IoT Ukey is a special type of Ukey with a built-in IoT SIM card, adding IoT functionality to the traditional Ukey. This type of Ukey can not only store and load device configuration information but also communicate with the cloud server via the network for remote management and control. Ukeys with built-in IoT SIM cards typically connect to the device via a USB interface and are operated using dedicated software or tools. The IoT Ukey is also considered a type of device asset; its permissions can be directly controlled from the cloud controller. One IoT Ukey can manage multiple devices, and it is plug-and-play, requiring no configuration or even an internet connection; it can be remotely connected to by the cloud controller simply by being plugged in.

[0071] The initial index file of the IoT Ukey includes:

[0072] Index file: The name must be USB_AR.ini or USB_ar.ini, and the content contains the serial number information of the IoT Ukey and the network card ismi;

[0073] Public key: The public key for accessing the cloud controller API, ctrl_pub.pub;

[0074] SSL Certificate: Used to create an SSL tunnel between the IoT Ukey and the cloud controller;

[0075] Status file: The file status.hash records the current status of the IoT Ukey. The content is a hash, and different hashes correspond to different statuses.

[0076] The file status.hash, which records the current IoT Ukey status, contains a hash, and different hashes correspond to different statuses, including:

[0077] The hash generated by authentication algorithm 1 is the device hash matched by the IoT Ukey. The hash allows the device to determine whether the IoT Ukey has recognized the device. Only after confirmation of recognition will subsequent processes proceed.

[0078] The hash generated by authentication algorithm 2 indicates that access to the cloud controller failed or the cloud controller returned an error. The cloud controller administrator needs to investigate the cause of the error.

[0079] Upon successful two-way authentication between the IoT Ukey and the cloud controller, an SSL tunnel is established between them. Through the SSL tunnel, communication data between the IoT Ukey and the cloud controller is encrypted to prevent interception or tampering by third parties. The SSL tunnel provides an authentication mechanism, ensuring that only verified IoT Ukeys and the cloud controller can communicate. It can also detect data tampering and guarantee data integrity.

[0080] The IoT Ukey and the device perform two-way authentication through the initial index file and authentication algorithm. The built-in IoT SIM card of the IoT Ukey is also a wireless network card and can be used directly as a temporary network. After the two-way authentication between the IoT Ukey and the device is completed, the cloud controller can remotely log in to the device directly through the SSL tunnel built between the IoT SIM card and the cloud. In this application, "device" refers to a network device.

[0081] After successful two-way authentication between the IoT Ukey and the device, the device requests the cloud controller's management API through the SSL tunnel established between the IoT Ukey and the cloud controller to obtain management configuration information. This management configuration information refers to the information required to manage a device within an IoT management platform. It typically includes the device's type, model, name, status, location, and network connection information.

[0082] The device automatically loads the managed configuration information and performs initial setup. Initial setup refers to the initial settings performed when the device starts up, including loading system files, configuring network parameters, and setting user permissions. This process is to ensure the device can start normally and begin operation.

[0083] Example 2

[0084] Figure 5 This is a schematic diagram of a zero-contact configuration system for terminal network devices based on an IoT SIM card Ukey, provided in one embodiment of this application. Figure 5 As shown, a zero-contact configuration system for terminal network devices based on an IoT SIM card Ukey is disclosed. The system includes:

[0085] The IoT Ukey and cloud controller two-way authentication module is used to perform two-way authentication between the IoT Ukey and the cloud controller through the IoT Ukey's initial index file and authentication algorithm;

[0086] An SSL tunnel module is established to enable the establishment of an SSL tunnel between the IoT Ukey and the cloud controller after successful two-way authentication.

[0087] The IoT Ukey and device two-way authentication module is used to perform two-way authentication between the IoT Ukey and the device through the initial index file of the IoT Ukey and the authentication algorithm;

[0088] The module for obtaining management configuration information is used when the IoT Ukey and the device successfully complete two-way authentication. The device requests the management API of the cloud controller through the SSL tunnel established between the IoT Ukey and the cloud controller to obtain management configuration information.

[0089] The initialization module is used for the device to automatically load the management configuration information and perform initialization.

[0090] Example 3

[0091] Figure 2 This is a schematic diagram of the two-way authentication process between the IoT Ukey and the cloud controller provided in one embodiment of this application, as shown below. Figure 2As shown, the two-way authentication process between the IoT Ukey and the cloud controller specifically includes:

[0092] For customers, an IoT Ukey is a device asset that needs to be registered with the cloud controller. This involves entering the device serial number (SN) and IMSI of the IoT Ukey. This information can be found on the tag attached to the Ukey. Each Ukey has a built-in public key (ctrl_pub.pub) for accessing the cloud controller, and authentication is performed using an authentication algorithm agreed upon by both parties.

[0093] The IoT Ukey uses its own SN and the hash_key calculated by ctrl_pub.pub as parameters to request the management API of the cloud controller;

[0094] The cloud controller receives the management API request from the cloud controller and does not verify whether the IoT Ukey's SN has been registered, because verifying SN registration requires querying the database, which wastes resources. It only verifies whether the SN and hash_key correspond. If the SN and hash_key correspond, it returns a token1 to the IoT Ukey.

[0095] The IoT Ukey receives the returned token1, calculates token2 using the authentication algorithm, and sends the SN and token2 again to request the cloud controller to manage the API.

[0096] The cloud controller receives the SN and token2. Based on the ability of token2 to authenticate the IoT Ukey client, it verifies whether the SN has been registered. If the SN is valid, it returns authentication success and token3 to the IoT Ukey.

[0097] Once the IoT Ukey receives the successful authentication and token3, it verifies token3 through the authentication algorithm, confirms that the cloud controller is a legitimate server, and then the IoT Ukey begins to establish an SSL tunnel with the cloud controller.

[0098] After the IoT Ukey establishes an SSL tunnel with the cloud controller, it can access the cloud controller interface.

[0099] Because the computing power of the IoT Ukey chip is limited, once an SSL tunnel is established between the IoT Ukey and the cloud controller, it can access some cloud interfaces and change different algorithms based on different device serial numbers, thereby increasing device security. The SN (Serial Number) is assigned to each IoT Ukey during production and remains unchanged throughout its lifecycle. The SN plays a crucial role in the communication between the IoT Ukey and the cloud controller. When registering with the cloud controller, the IoT Ukey needs to provide its own SN, and the cloud controller verifies this SN to determine the legitimacy of the IoT Ukey.

[0100] Example 4

[0101] Figure 3 This is a schematic diagram of the IoT Ukey and device two-way authentication process provided in one embodiment of this application, as shown below. Figure 3 As shown, the IoT Ukey and device two-way authentication process includes:

[0102] After the IoT Ukey is inserted into the device, the device can see whether the initial index file USB_AR.ini exists through the USB hook. If the initial index file USB_AR.ini does not exist, the process will stop.

[0103] If the initial index file USB_AR.ini exists, the device obtains the IoT Ukey information from the initial index file and writes the device information into device_info.ini;

[0104] Write device_info.ini into the IoT Ukey;

[0105] The IoT Ukey sends the written device_info.ini file and its own IoT Ukey information as parameters to the cloud controller to verify the legality of the device information;

[0106] After verifying the legitimacy of the network device, calculate hash1 of authentication algorithm 1;

[0107] Hash1 is written to the status.hash file;

[0108] Network devices use authentication algorithm 1 to calculate hash2 using Ukey information and their own information;

[0109] The network device polls the status.hash file. If it finds that hash1 in the status.hash file is the same as the calculated hash2, the network device completes the authentication of the IoT Ukey and uses authentication algorithm 1 to calculate hash3 based on hash1 and writes it into the status.hash file.

[0110] After receiving the hash3, the IoT Ukey requests the cloud controller to verify the correctness of the hash3.

[0111] After verification, the IoT Ukey completes the authentication of the device's legitimacy.

[0112] Before the IoT Ukey is used for device authentication, the device's USB interface can only read data from the device, not write data to it. However, if the inserted USB device has a startup index file USB_AR.ini, a device_info.ini file will be written to the USB device by default, recording device information, including the device serial number (SN), software version number, device model, random number, and device time. This information can be seen on the label on the back of the device or directly after the device is powered on.

[0113] Each IoT Ukey and device has a unique serial number (SN). After the IoT Ukey connects to the cloud controller, it uses the information in device_info.ini as a parameter to request the cloud API for device authentication algorithm 1, obtains hash1 of algorithm 1, and writes it to the status file status.hash. The device will also implement the same authentication algorithm to calculate hash2, compare it with hash1 in the status.hash file, and complete the device authentication of the Ukey after successful verification.

[0114] After the device completes authentication, it uses the authentication algorithm to calculate a hash3 and writes it to status.hash. The IoT Ukey will then directly send the hash3 request to the cloud authentication interface. After successful authentication, the two-way authentication between the IoT Ukey and the device is completed.

[0115] Example 5

[0116] Figure 4 This is a schematic diagram illustrating the process of enabling and activating services using management information obtained through an IoT Ukey, as provided in one embodiment of this application. Figure 4 As shown, the process for initial setup and service activation using the management information obtained through the IoT Ukey includes:

[0117] An SSL tunnel was successfully established between the IoT Ukey and the cloud controller, and the IoT Ukey and the device successfully completed two-way authentication.

[0118] The device requests and downloads the management API of the cloud controller via an SSL tunnel;

[0119] The cloud controller verifies the legality of device information;

[0120] Once the device information is verified to be valid, the cloud controller returns the management configuration information to the device.

[0121] The device automatically loads the configuration information and initiates operation.

[0122] Example 6

[0123] Figure 6 This is a schematic diagram of an electronic device structure provided in one embodiment of this application. Figure 6 As shown, according to another aspect of this application, an electronic device 500 is also provided. The electronic device 500 may include one or more processors and one or more memories. The memories store computer-readable code, which, when executed by the one or more processors, can perform a method for measuring the end-to-end latency of a cloud computer.

[0124] The method or system according to the embodiments of this application can also be used by means of Figure 6 The architecture of the electronic device shown is used to implement this. For example... Figure 6 As shown, the electronic device 500 may include a bus 501, one or more CPUs 502, a read-only memory (ROM) 503, a random access memory (RAM) 504, a communication port 505 connected to a network, an input / output component 506, a hard disk 507, etc. The storage device in the electronic device 500, such as the ROM 503 or the hard disk 507, may store a cloud computer end-to-end latency measurement method provided in this application. A zero-contact configuration method for a terminal network device based on an IoT SIM card (Ukey) may include, for example, the following steps: The IoT Ukey and a cloud controller perform bidirectional authentication using the Ukey's initialization index file and authentication algorithm; upon successful bidirectional authentication, an SSL tunnel is established between the IoT Ukey and the cloud controller; the IoT Ukey and the device perform bidirectional authentication using the Ukey's initialization index file and authentication algorithm; upon successful bidirectional authentication, the device requests the cloud controller's management API through the SSL tunnel established between the IoT Ukey and the cloud controller to obtain management configuration information; the device automatically loads the management configuration information and performs initialization. Further, the electronic device 500 may also include a user interface 508. Of course, Figure 6 The architecture shown is merely exemplary and can be omitted as needed when implementing different devices. Figure 6 One or more components in the illustrated electronic device.

[0125] Example 7

[0126] Figure 7 This is a schematic diagram of a computer-readable storage medium structure provided in one embodiment of this application. Figure 7The diagram illustrates a computer-readable storage medium 600 according to one embodiment of this application. The computer-readable storage medium 600 stores computer-readable instructions. When executed by a processor, the computer-readable instructions can perform a zero-contact configuration method for a terminal network device based on an IoT card Ukey, as described above with reference to the accompanying drawings, according to an embodiment of this application. The storage medium 600 includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc.

[0127] It should be understood that the methods and apparatus of this application can be implemented in many ways. For example, the methods and apparatus of this application can be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the method is for illustrative purposes only, and the steps of the method of this application are not limited to the order specifically described above, unless otherwise specifically stated. Furthermore, in some embodiments, this application may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the method according to this application. Therefore, this application also covers recording media storing programs for performing the method according to this application.

[0128] In addition, the parts of the technical solutions provided in the embodiments of this application that are consistent with the implementation principles of the corresponding technical solutions in the prior art have not been described in detail, so as to avoid excessive elaboration.

[0129] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A zero-contact configuration method for terminal network devices based on IoT SIM card Ukey, characterized in that, Includes the following steps: The IoT SIM Ukey and the cloud controller perform two-way authentication through the initial index file and authentication algorithm. The IoT SIM Ukey and the cloud controller successfully completed two-way authentication, and an SSL tunnel was established between the IoT SIM Ukey and the cloud controller. The IoT SIM Ukey and the device perform two-way authentication through the initial index file and authentication algorithm of the IoT SIM Ukey; After successful two-way authentication between the IoT SIM Ukey and the device, the device requests the management API of the cloud controller through the SSL tunnel established between the IoT SIM Ukey and the cloud controller to obtain management configuration information. The device automatically loads the management configuration information and initiates operation. Wherein, the IoT card Ukey refers to the Ukey of the built-in IoT card; The initial index file of the IoT card Ukey includes: Index file: The name must be USB_AR.ini or USB_ar.ini, and the content contains the serial number information of the IoT card Ukey and the network card ismi; Public key: The public key for accessing the cloud controller API, ctrl_pub.pub; SSL Certificate: Used to create an SSL tunnel between the IoT SIM card Ukey and the cloud controller; Status file: The file status.hash records the current status of the IoT card Ukey. The content is a hash, and different hashes correspond to different statuses. The steps for establishing an SSL tunnel between the IoT SIM card Ukey and the cloud controller after successful two-way authentication include: The IoT SIM card Ukey uses its own SN and the hash_key calculated by ctrl_pub.pub as parameters to request the cloud controller's API for management. The cloud controller receives the cloud controller management API request, verifies whether the SN and hash_key are corresponding, and if the SN and hash_key are corresponding, it returns a token1 to the IoT card Ukey. The IoT card Ukey receives the returned token1, calculates token2 through the authentication algorithm, and sends the SN and token2 again to request the cloud controller to manage the API; The cloud controller receives the SN and token2. Based on token2, it can authenticate the IoT card Ukey client as legitimate and verify whether the SN has been registered. If the SN is valid, the IoT card Ukey will return a successful authentication and token3 to the IoT card Ukey. Once the IoT SIM Ukey receives the successful authentication and token3, it verifies token3 through the authentication algorithm, confirms that the cloud controller is a legitimate server, and then the IoT SIM Ukey begins to establish an SSL tunnel with the cloud controller. The steps for two-way authentication between the IoT SIM card Ukey and the device include: After the IoT SIM card Ukey is inserted into the device, the device can detect whether the initial index file USB_AR.ini exists via the USB hook; If the initial setup index file exists, the device retrieves the IoT SIM card Ukey information from the initial setup index file and writes the device information to device_info.ini; The IoT SIM card Ukey uses the current device_info.ini file and its own IoT SIM card Ukey information as parameters to request the cloud controller to verify the legality of the device information; After verifying the legitimacy of the network device, calculate hash1 of authentication algorithm 1; Hash1 is written to the status.hash file; Network devices use authentication algorithm 1 to calculate hash2 using IoT SIM card Ukey information and their own information; The network device polls the status.hash file. If it finds that hash1 in the status.hash file is the same as the calculated hash2, the network device completes the authentication of the IoT card Ukey and uses authentication algorithm 1 to calculate hash3 based on hash1 and write it into the status.hash file. After receiving the hash3, the IoT SIM card Ukey requests the cloud controller to verify the correctness of the hash3. After verification, the IoT card Ukey completes the authentication of the device's legitimacy.

2. The zero-contact configuration method for terminal network devices based on IoT SIM card Ukey according to claim 1, characterized in that, The file status.hash, which records the current status of the IoT SIM card Ukey, contains a hash, and different hashes correspond to different statuses, including: The hash generated by authentication algorithm 1 is the device hash matched with the IoT card Ukey. The hash allows the device to determine whether the IoT card Ukey has recognized the device. Only after confirmation of recognition will the subsequent process proceed. The hash generated by authentication algorithm 2 indicates that access to the cloud controller failed or the cloud controller returned an error. The cloud controller administrator needs to investigate the cause of the error.

3. The zero-contact configuration method for terminal network devices based on IoT SIM card Ukey according to claim 1, characterized in that, The steps for the device to automatically load the network configuration information and perform initial setup include: An SSL tunnel was successfully established between the IoT SIM Ukey and the cloud controller, and the IoT SIM Ukey and the device successfully completed two-way authentication. The device requests and downloads the management API of the cloud controller via an SSL tunnel; The cloud controller verifies the legality of device information; Once the device information is verified to be valid, the cloud controller returns the management configuration information to the device. The device automatically loads the configuration information and initiates operation.

4. A zero-contact configuration system for terminal network devices based on an IoT SIM card (Ukey), characterized in that, The system includes: The IoT SIM Ukey and cloud controller two-way authentication module is used to perform two-way authentication between the IoT SIM Ukey and the cloud controller through the initial index file and authentication algorithm of the IoT SIM Ukey. The IoT SIM Ukey refers to the Ukey with the built-in IoT SIM card. An SSL tunnel module is established to enable the establishment of an SSL tunnel between the IoT SIM Ukey and the cloud controller after successful two-way authentication. The IoT SIM Ukey and device two-way authentication module is used to perform two-way authentication between the IoT SIM Ukey and the device through the initial index file of the IoT SIM Ukey and the authentication algorithm; The module for obtaining management configuration information is used when the IoT SIM Ukey and the device successfully complete two-way authentication. The device then requests the management API of the cloud controller through the SSL tunnel established between the IoT SIM Ukey and the cloud controller to obtain management configuration information. The initialization module is used for the device to automatically load the management configuration information and perform initialization. The initial index file of the IoT SIM Ukey includes: an index file, whose name must be USB_AR.ini or USB_ar.ini, containing the serial number information of the IoT SIM Ukey and the network interface card (ismi); a public key, which is the public key ctrl_pub.pub for accessing the cloud controller API; an SSL certificate, used to create an SSL tunnel between the IoT SIM Ukey and the cloud controller; and a status file, which is a file status.hash that records the current status of the IoT SIM Ukey, containing a hash, with different hashes corresponding to different statuses. The specific function of the two-way authentication module between the IoT SIM Ukey and the cloud controller is as follows: The IoT SIM Ukey sends its own SN and the hash_key calculated by ctrl_pub.pub as parameters to request the cloud controller's management API; The cloud controller receives the management API request, verifies whether the SN and hash_key correspond, and if they do, returns a token1 to the IoT SIM Ukey; The IoT SIM Ukey receives the returned token1, calculates token2 using the authentication algorithm, and sends the SN and token2 again to request the cloud controller's management API; The cloud controller receives the SN and token2, verifies that the IoT SIM Ukey client is legitimate based on token2, verifies whether the SN is registered, and if so, returns authentication success and token3 to the IoT SIM Ukey; The IoT SIM Ukey receives authentication success and token3, confirms token3 using the authentication algorithm, confirms that the cloud controller is a legitimate server, and the IoT SIM Ukey begins to establish an SSL tunnel with the cloud controller; The IoT SIM Ukey and device two-way authentication module is specifically used for the following: After the IoT SIM Ukey is inserted into the device, the device can see whether the initial index file USB_AR.ini exists through USBhook; if the initial index file exists, the device obtains the IoT SIM Ukey information from the initial index file and writes the device information to device_info.ini; the IoT SIM Ukey uses the current device_info.ini and its own IoT SIM Ukey information as parameters to request the cloud controller to verify the legality of the device information; after verifying the legality of the network device, it calculates hash1 of authentication algorithm 1; hash 1. Write the hash to the status.hash file; 2. The network device calculates hash2 using authentication algorithm 1 based on the IoT SIM card Ukey information and its own information; 3. The network device polls the status.hash file. If it finds that hash1 in the status.hash file is the same as the calculated hash2, the network device completes the authentication of the IoT SIM card Ukey, calculates hash3 based on hash1 using authentication algorithm 1, and writes it to the status.hash file; 4. After receiving hash3, the IoT SIM card Ukey requests the cloud controller to verify the correctness of hash3; 5. After verification, the IoT SIM card Ukey completes the authentication of the device's legitimacy.

5. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in the zero-contact configuration method for a terminal network device based on an IoT SIM card Ukey as described in any one of claims 1-3.

6. A readable storage medium, characterized in that, The readable storage medium stores a computer program adapted for loading by a processor to execute a zero-contact configuration method for terminal network devices based on an IoT SIM card Ukey as described in any one of claims 1-3.

Images