CN115730352A - Method for replacing equipment, debugging tool, hardware equipment and device - Google Patents

Method for replacing equipment, debugging tool, hardware equipment and device Download PDF

Info

Publication number
CN115730352A
CN115730352A CN202111005965.6A CN202111005965A CN115730352A CN 115730352 A CN115730352 A CN 115730352A CN 202111005965 A CN202111005965 A CN 202111005965A CN 115730352 A CN115730352 A CN 115730352A
Authority
CN
China
Prior art keywords
private key
certificate
hardware
key
tool
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111005965.6A
Other languages
Chinese (zh)
Inventor
李红蕊
齐麟
贾贺朋
张立伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to CN202111005965.6A priority Critical patent/CN115730352A/en
Publication of CN115730352A publication Critical patent/CN115730352A/en
Pending legal-status Critical Current

Links

Images

Abstract

The embodiment of the application provides a device replacement method, a debugging tool, hardware equipment and a device for device replacement, and can effectively ensure the normal operation of communication of an Internet of things system under the condition that certain equipment in the Internet of things system is damaged. The device replacement method comprises the following steps: the method comprises the steps that a debugging tool obtains a first certificate and a first private key of first equipment, the first private key is obtained by encrypting the private key of the first equipment by hardware equipment through a public key of second equipment, the hardware equipment is used for encrypting and decrypting the key, the second equipment is replacement equipment of the first equipment, and the first certificate is used for enabling the first equipment to be accessed into an Internet of things system before the second equipment replaces the first equipment; the debugging tool sends a first private key and a first certificate to the second device, the first private key is used for the second device to obtain the private key of the first device, and the private key of the first device and the first certificate are used for the second device to replace the first device.

Description

Method for replacing equipment, debugging tool, hardware equipment and device
Technical Field
The present application relates to the field of internet of things (IoT), and more particularly, to a method of device replacement, a commissioning tool, a hardware device, and an apparatus.
Background
The IoT is a network that obtains information of the physical world by deploying various devices with certain capabilities of sensing, computing, executing, and communicating with the development of information technology and sensor technology, and realizes transmission, cooperation, and processing of information through a network, thereby realizing human-to-object communication and interconnection of object-to-object communication, and bringing convenient life style and working style to social life.
Today, more and more devices access the IoT system. Typically, a Registrar (registry) is used to decide whether to allow a new device to access the IoT system. In some cases, the registry may be unavailable. If the registry is not available, it will prevent new devices from accessing the IoT system, which may cause serious inconvenience. For example, if a device in the IoT system is damaged, a new device needs to be replaced, but the registration server cannot access the IoT system without using the new device.
Disclosure of Invention
The application provides a device replacement method, a debugging tool, hardware equipment and a device, which can effectively ensure the normal operation of the communication of an Internet of things system under the condition that a certain device in the Internet of things system is damaged.
In a first aspect, a method for device replacement is provided, including: a debugging tool acquires a first certificate and a first private key of first equipment, wherein the first private key is obtained by encrypting the private key of the first equipment by hardware equipment through a public key of second equipment, the hardware equipment is used for encrypting and decrypting the key, the second equipment is replacement equipment of the first equipment, and the first certificate is used for accessing the first equipment to an Internet of things system before the second equipment replaces the first equipment; the debugging tool sends the first private key and the first certificate to the second device, wherein the first private key is used for the second device to obtain the private key of the first device, and the private key of the first device and the first certificate are used for the second device to replace the first device.
According to the technical scheme, under the condition that the second device needs to replace the first device, the debugging tool forwards the first certificate and the first private key to the second device after acquiring the first certificate and the first private key of the first device, so that the second device can acquire the private key of the first device based on the first private key and replace the first device based on the private key of the first device and the first certificate of the first device. According to the technical scheme, the certificate does not need to be issued to the second device, and parameters such as the serial number do not need to be configured for the second device again, so that the purpose that the second device replaces the first device can be achieved in a short time, and the processing speed is effectively improved.
Further, by introducing a hardware device for performing encryption and decryption operations on a key, such as the private key of the first device, the security of the private key of the first device is guaranteed.
In some possible implementations, the method further includes: the debugging tool acquires a second private key and a second certificate of the second device, wherein the second certificate is a certificate issued by a manufacturer for the second device and comprises a public key of the second device, and the second private key is obtained by encrypting the private key of the first device by adopting the public key of the hardware device; the debugging tool sending the second private key and the second certificate to the hardware device; the debugging obtains a first private key, comprising: the debugging tool receives the first private key sent by the hardware device.
According to the technical scheme, the first device encrypts the private key of the first device by using the public key of the hardware device, and the private key of the hardware device for decrypting the private key of the first device is only stored in the hardware device, so that other devices cannot acquire the private key of the hardware device from the hardware device, so that the security of the private key of the first device can be improved, and the attack of malicious devices can be prevented. In addition, the second certificate of the second device includes the public key of the second device, the debugging tool sends the second certificate to the hardware device, the hardware device can subsequently encrypt the private key of the first device by using the public key of the second device in the second certificate, and thus the private key of the first device can be decrypted only by the second device, and the security of the private key of the first device is further ensured.
In some possible implementations, the obtaining, by the debugging tool, the second private key includes: the debugging tool receives a second private key sent by the first device; the debug tool stores the second private key.
In some possible implementations, the obtaining, by the commissioning tool, the second certificate of the first device includes: the debugging tool establishes a Transport Layer Security (TLS) connection with the second device; and the debugging tool receives the second certificate sent by the second equipment through the TLS connection.
In some possible implementations, the method further includes: the debugging tool establishes the mapping relation according to the attribute information of the first equipment and the attribute information of the second equipment, wherein the attribute information comprises a serial number and/or a Media Access Control (MAC) address; and the debugging tool verifies the second certificate according to the mapping relation.
According to the technical scheme, after the debugging tool receives the second certificate, the second certificate is verified according to the mapping relation between the first equipment and the second equipment, tampering of the second certificate by malicious equipment can be prevented, and accuracy of the second certificate is effectively guaranteed.
Further, since the serial number and the MAC address of the device may be parameters that best reflect the identity of the device, the mapping relationship between the first device and the second device determined according to the serial number and/or the MAC address may be effectively distinguished from other devices. Further, by establishing the mapping relationship, the debugging tool can communicate with the second device based on the mapping relationship, so that the problem that the devices except the second device also acquire the private key and the first certificate of the first device is avoided, and the security of the private key and the first certificate of the first device is ensured.
In some possible implementations, the method further includes: the debugging tool receives a public key of the hardware device sent by the hardware device; the debug tool sends the public key of the hardware device to the first device.
In some possible implementations, the first certificate is a certificate that the registrar issued to the first device if available; the commissioning tool obtaining a first certificate for a first device, comprising: the debugging tool receives the first certificate sent by the register; the commissioning tool storing the first certificate; the debug tool obtaining a first private key, comprising: the debug tool obtains the first private key when the registrar is unavailable.
Since the registrar decides whether to allow a new device to join the system of things, the device can only join the system of things if it obtains the certificate that the registrar issued it, and if other means, such as a commissioning tool, were used instead of the registrar to issue a certificate for the new device in the event that the registrar is unavailable, then the means for replacing the registrar would need to obtain the key of the registrar, which is extremely insecure. According to the technical scheme, under the condition that the register is unavailable, the debugging tool acquires the first certificate and the first private key which are required by the second equipment to replace the first equipment, so that the register is not replaced by other devices to issue the certificate for the second equipment, the problem that other equipment acquires the private key of the register in order to issue the certificate of the second equipment is solved, the private key of the register is guaranteed to be only stored in the register, and the safety of the whole system is improved to a great extent.
In a second aspect, a method for device replacement is provided, including: the hardware device receives a second private key sent by a debugging tool, wherein the second private key is obtained by encrypting the private key of the first device by adopting the public key of the hardware device; the hardware device decrypts the second private key by adopting the private key of the hardware device to obtain the private key of the first device; the hardware device encrypts a private key of the first device by adopting a public key of a second device to obtain a first private key, wherein the second device is a replacement device of the first device; and the hardware device sends the first private key to the debugging tool, wherein the first private key is used for the second device to obtain the private key of the first device.
According to the technical scheme, under the condition that the first equipment needs to be replaced by the second equipment, the hardware equipment is introduced, and the public key and the private key generated by the hardware equipment are utilized to realize encryption and decryption of the private key of the first equipment. The private key of the hardware device for decryption is only stored in the hardware device, and the private key of the hardware device cannot be extracted from the hardware device by other devices, so that the security of the private key of the first device is improved, and the attack of malicious devices is prevented. Furthermore, the hardware device encrypts the private key of the first device by using the public key of the second device in the second certificate, so that the private key of the first device can be decrypted only by the second device, and the security of the private key of the first device is further ensured.
In some possible implementations, the method further includes: the hardware device receives a second certificate of the second device sent by the debugging tool, wherein the second certificate is a certificate issued by a manufacturer for the second device and comprises a public key of the second device.
In some possible implementations, the method further includes: the hardware device sends a public key of the hardware device to the debug tool.
In a third aspect, a method for device replacement is provided, including: the method comprises the steps that a second device obtains a first certificate of a first device and a private key of the first device, wherein the first certificate is used for accessing the Internet of things system by the first device before the second device replaces the first device; the second device replaces the first device based on the first certificate and the private key of the first device.
According to the technical scheme, under the condition that the second device needs to replace the first device, the second device can replace the first device based on the private key of the first device and the first certificate of the first device after acquiring the first certificate and the first private key, a register does not need to issue a certificate for the second device, and parameters such as a serial number do not need to be configured for the second device, so that the purpose of replacing the first device can be achieved in a short time, and the processing speed is effectively improved.
In some possible implementations, the obtaining, by the second device, the private key of the first device includes: the second device receives a first private key sent by a debugging tool, wherein the first private key is obtained by encrypting the private key of the first device by the hardware device by adopting a public key of the second device; and the second equipment decrypts the first private key by adopting the private key of the second equipment to obtain the private key of the second equipment.
In some possible implementations, the method further includes: the second device sends a second certificate of the second device to a commissioning tool through a Transport Layer Security (TLS) connection, wherein the second certificate manufacturer is a certificate issued by the second device and includes a public key of the second device.
In some possible implementations, the first certificate is a certificate that the registrar issued to the first device if available; the second device obtaining a first certificate of the first device, including: when the registrar is not available, the second device receives the first certificate sent by a commissioning tool.
Since the registrar decides whether to allow a new device to join the system of things, the device can only join the system of things if it obtains the certificate that the registrar issued it, and if other means, such as a commissioning tool, were used instead of the registrar to issue a certificate for the new device in the event that the registrar is unavailable, then the means for replacing the registrar would need to obtain the key of the registrar, which is extremely insecure. According to the technical scheme, under the condition that the register is unavailable, the second device can replace the first device by obtaining the private key and the first certificate of the first device, and does not use other devices to replace the register to issue the certificate for the second device, so that the safety of the whole system is improved to a great extent.
In a fourth aspect, a method of device replacement is provided, comprising: the method comprises the steps that a first device obtains a public key of a hardware device; the first equipment encrypts a private key of the first equipment by adopting a public key of the hardware equipment to obtain a second private key; the first device sends the second private key and a first certificate of the first device to a commissioning tool, the first certificate being used for the first device to access an internet of things system and for the second device to replace the first device before the second device replaces the first device.
In a fifth aspect, a debugging tool is provided, comprising means for performing the method of the first aspect or its implementations.
A sixth aspect provides a hardware device comprising means for performing the method of the second aspect or its implementations.
In a seventh aspect, an apparatus for device replacement is provided, which includes means for performing the method in the third aspect or its implementations.
In an eighth aspect, an apparatus for device replacement is provided, which includes means for performing the method in the fourth aspect or its implementations.
In a ninth aspect, there is provided a debugging tool comprising: a memory for storing a program; a processor configured to execute the program stored in the memory, and when the program stored in the memory is executed, the processor is configured to perform the method of the first aspect or each implementation manner thereof.
In a tenth aspect, there is provided a hardware device comprising: a memory for storing a program; a processor for executing the program stored in the memory, and when the program stored in the memory is executed, the processor is configured to perform the method of the second aspect or each implementation manner thereof.
In an eleventh aspect, an apparatus for device replacement is provided, including: a memory for storing a program; a processor configured to execute the program stored in the memory, and when the program stored in the memory is executed, the processor is configured to perform the method of the third aspect or each implementation manner thereof.
In a twelfth aspect, an apparatus for device replacement is provided, including: a memory for storing a program; a processor configured to execute the program stored in the memory, and when the program stored in the memory is executed, the processor is configured to perform the method of the fourth aspect or each implementation manner thereof.
Drawings
FIG. 1 is a schematic flow diagram of a device joining system with Registrar available.
Fig. 2 is a schematic diagram of a method of device replacement of an embodiment of the present application.
Fig. 3 is a schematic diagram of another method of device replacement of an embodiment of the present application.
Fig. 4 is a schematic diagram of yet another method of device replacement according to an embodiment of the present application.
Fig. 5 is a schematic diagram of yet another method of device replacement according to an embodiment of the present application.
Fig. 6 is a schematic flow chart of a method of device replacement according to an embodiment of the present application.
FIG. 7 is a schematic block diagram of a debugging tool of an embodiment of the present application.
Fig. 8 is a schematic block diagram of a hardware device according to an embodiment of the present application.
Fig. 9 is a schematic block diagram of an apparatus alternative to the device of the embodiments of the present application.
Fig. 10 is a schematic block diagram of an apparatus alternative to the device of the embodiments of the present application.
Fig. 11 is a schematic block diagram of an apparatus of an embodiment of the present application.
List of reference numerals:
a; a device A;
c: debugging a tool;
R:Registrar;
110-180, steps of method 100;
210, the debugging tool obtains a first certificate and a first private key of the first device;
220, the debugging tool sends the first private key and the first certificate to the second device;
310, the hardware device receives the second private key sent by the debugging tool;
the hardware device decrypts the second private key by using the private key of the hardware device 320 to obtain the private key of the first device;
330, the hardware device encrypts the private key of the first device by using the public key of the second device to obtain a first private key;
340, the hardware device sends a first private key to the debugging tool;
410, the second device obtains a first certificate of the first device and a private key of the first device;
the second device replacing 420 the first device based on the first certificate and the private key of the first device;
510, a first device acquires a public key of a hardware device;
520, the first device encrypts the private key of the first device by using the public key of the hardware device to obtain a second private key;
the first device sends 530 the second private key and the first certificate of the first device to the commissioning tool.
X, a second device;
h: a hardware device;
601-623, steps of method 600;
700, a debugging tool;
710, an acquisition unit;
720, a communication unit;
800, a hardware device;
810, a communication unit;
820, a decryption unit;
830, an encryption unit;
900, device replacement;
910, an acquisition unit;
920, a processing unit;
1000, equipment replacement means;
1010, an acquisition unit;
1020, an encryption unit;
1030, a communication unit;
1100, a device;
1101, a memory;
1102, a processor;
1103, a communication interface;
1104, a bus.
Detailed Description
The technical solutions in the embodiments of the present application are described below with reference to the accompanying drawings. It should be understood that the specific examples in this specification are provided solely to assist those skilled in the art in better understanding the embodiments of the present application and are not intended to limit the scope of the embodiments of the present application.
It should be understood that, in the various embodiments of the present application, the size of the serial number of each process does not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.
It should also be understood that the various embodiments described in this specification can be implemented individually or in combination, and are not limited to the examples in this application.
Unless otherwise defined, all technical and scientific terms used in the examples of this application have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in the present application is for the purpose of describing particular embodiments only and is not intended to limit the scope of the present application.
The IoT is a network that enables all common physical objects capable of being addressed independently to implement rendezvous and interworking based on information bearers such as the internet and a traditional telecommunication network. With the deep development of IoT, various types of IoT devices start to access the IoT system.
The IoT devices may be radio frequency identification devices, sensors, global positioning system devices, laser scanners, smart home devices, commercial building devices, and the like. When the IoT device is a commercial building device, the IoT device may include, but is not limited to, a lighting device, a thermostat, a dimmer, etc., which are collectively referred to as FA-devices in the embodiments of the present application. The IoT system may be referred to as an FA-system at this time. It should be understood that the embodiments of the present application are not limited thereto.
The FA-device may also have at least one network interface, such as an ethernet interface or a wireless local area network interface. Further, the FA-device may also have internet networking capabilities to communicate with other devices, such as may be based on the network interface described above.
The Registrar (registry) decides whether to allow the FA-device to access the FA-system. If an FA-device is allowed to access the FA-system, the registry may issue a digital certificate (hereinafter referred to as certificate) to the FA-device.
Since the FA-device cannot access the FA-system by itself, the FA-device can access the FA-system through a commissioning tool (commissioning tool). Illustratively, the debugging tool may be a personal computer, a palm top computer, a tablet computer, a smart terminal or a Personal Digital Assistant (PDA), etc. The debugging tool can act as an intermediary between the FA-device and the registry, for example, forwarding a registration request sent by the FA-device to the registry, and for example, forwarding a certificate issued by the registry for the FA-device to the FA-device.
Fig. 1 shows a schematic flow diagram of a method 100 for one possible FA-device to access a FA-system in the Fairhair standard. In fig. 1, the FA-device is device a.
At 110, the commissioning tool sends a first registration request message to device a indicating that device a requests access to the FA-system, since device a cannot actively send a registration request.
At 120, device a receives the first registration request message and generates a key pair including a public key (public key) and a private key (private key).
The private key is a secret key stored in the device a itself, and the public key is a secret key that can be published to other devices, for example, the device a may broadcast the generated public key through bluetooth. Alternatively, device a may run a web browser based on an ethernet interface or a wireless local area network interface, exposing the public key in the web page.
The key pair generated by device a may also be referred to as a local device identifier (LDevID) key pair. For example, if the device a is located in a building, the LDevID is an identifier of the device a in the building, i.e., the LDevID may be an identification provided by an administrator of the building for the device a.
Corresponding to the LDevID is an initial device identifier (IDevID), which is a declaration of FA-device manufacturer to FA-device unique identity, and the IDevID subject field may include an attribute with FA-device unique serial number (serial number). That is, the IDevID is an identification provided by the FA-device (e.g., device a) by the manufacturer device when the FA-device is shipped from the factory. It can be seen that the main difference between LDevID and IDevID is the difference in the providers of the identifiers.
In 130, device a sends a second registration request message to the commissioning tool.
The second registration request message may be used as a response to the first registration request message to instruct device a to request access to the FA-system.
At 140, the debug tool forwards the second registration request message to the registry.
At 150, registrar issues a digital certificate (referred to simply as a certificate) for device A.
The certificate of device a may include public key information (subject public key Info) of device a, name (subject) of device a, and signature (signature) of registry. The public key information may include device a's public key and public key algorithm information, the signature of Registrar being the signature of Registrar on a certificate using its own private key.
In addition, the certificate of the device a may further include information such as a serial number (serial number) of the device a, a name (certificate) of the registry, a validity (validity) of the certificate, and the like.
Before the Registrar issues a certificate for device a, the Registrar may verify the second registration request message to verify whether the second registration request message was sent by device a. If the second registration request message is sent by device a, the registry issues a certificate for device a.
The second registration request message may include a public key generated by the device a, the registry may compare the public key in the second registration request message with the obtained public key of the device a, and if the public key in the second registration request message is the same as the obtained public key of the device a, the registry issues a certificate for the device a.
Further, the second registration request message may further include identification information of device a, and the registry may determine, according to the identification information of a, that the second registration request message is sent by device a, and then issue a certificate for device a.
At 160, the registry sends a first registration request response message to the debug tool, where the first registration response message includes a certificate issued by the registry for device a.
At 170, the commissioning tool receives the first registration request response message and forwards the first registration request response message to device a.
In 180, after receiving the first registration request response message, the device a accesses the FA-system based on the certificate in the first registration request response message.
In the process of accessing the FA-system by the FA-device shown in fig. 1, it can be seen that the FA-device needs to issue a certificate for the FA-system to access. In some cases, however, it may happen that Registrar is not available. If Registrar is not available, it is not possible for a new FA-device to access the FA-system, which may cause serious troubles. For example, if a device (e.g., device a in fig. 1) in the FA-system is damaged, a new device needs to be replaced, but the new device cannot access the FA-system because registry is unavailable.
Based on this, the embodiment of the present application provides a device replacement method, which can replace a damaged device with a new device in a shorter time when a certain device in an FA-system is damaged, thereby ensuring normal operation of communication in the FA-system.
The method for replacing the device according to the embodiment of the present application can be applied to, but is not limited to, the Fairhair standard.
Fig. 2 shows a schematic flow diagram of a method 200 of device replacement of an embodiment of the present application. Method 200 may be performed by a debugging tool, which may be the debugging tool in FIG. 1. The method 200 may include at least some of the following.
In 210, a first certificate and a first private key of a first device are obtained, where the first private key is obtained by encrypting, by a hardware device, a private key of the first device with a public key of a second device, the second device is a replacement device of the first device, and the first certificate is used for accessing the first device to the internet of things system before the second device replaces the first device.
In 220, a first private key and a first certificate are sent to the second device, the first private key is used by the second device to obtain the private key of the first device, and the private key of the first device and the first certificate are used by the second device to replace the first device.
Fig. 3 shows a schematic flow chart of a method 300 of device replacement of an embodiment of the present application. The method 300 may be performed by a hardware device and may include at least some of the following.
At 310, a second private key sent by the debugging tool is received, where the second private key is obtained by the first device encrypting the private key of the first device by using the public key of the hardware device.
At 320, the second private key is decrypted using the private key of the hardware device to obtain the private key of the first device.
In 330, the hardware device encrypts the private key of the first device with the public key of the second device to obtain the first private key, where the second device is a replacement device of the first device.
In 340, a first private key is sent to the commissioning tool, the first private key being used by the second device to obtain a private key of the first device.
Fig. 4 shows a schematic flow chart of a method 400 of device replacement of an embodiment of the present application. The method 400 may be performed by a second device that is an alternate device to the first device. The method 400 may include at least some of the following.
In 410, the second device obtains a first certificate of the first device and a private key of the first device, the first certificate being used for the first device to access the system of things before the second device replaces the first device.
In 420, the second device replaces the first device based on the first certificate and the private key of the first device.
Fig. 5 is a schematic flow chart diagram of a method 500 for device replacement in an embodiment of the present application. The method 500 may be performed by a first device. The method 500 may include at least some of the following.
At 510, the first device obtains a public key of the hardware device.
At 520, the first device encrypts the private key of the first device with the public key of the hardware device to obtain a second private key.
In 530, the first device sends the second private key and a first certificate of the first device to the commissioning tool, the first certificate being used for the first device to access the internet of things system and for the second device to replace the first device before the second device replaces the first device.
The method of device replacement of the embodiments of the present application will be further described below in conjunction with fig. 2-5. It should be understood that, in the embodiment, the angle is described from the debugging tool side, it is understood that Y is received from R, meaning that R is sent, for example, the hardware device receives the second private key from the debugging tool, meaning that the debugging tool sends the second private key to the hardware device.
The first device in fig. 2-5 may be device a in fig. 1, which is damaged and needs to be replaced. For example, if the first device is an air conditioner, the air conditioner cannot cool or heat; for another example, if the first device is a lighting device, a fuse of the lighting device melts due to overheating, so that the lighting device cannot emit light.
The hardware device of the embodiment of the present application may be used to encrypt and decrypt the key, for example, may be used to decrypt the second private key, and for example, may be used to encrypt the private key of the first device.
Alternatively, the private key of the hardware device used for decryption may be stored only in the hardware device, and the private key of the hardware device cannot be extracted from the hardware device by other devices.
Alternatively, a hardware device may be inserted in the debugging tool, and the hardware device may be, for example, a Universal Serial Bus Flash disk (usb disk, for short), or may be a device similar to the usb disk.
Alternatively, in fig. 2-5, registry is not available, e.g., registry is damaged, or devices in the current range have all access to the FA-system, registry considers its task to be completed and thus is in a dormant state.
Since the registry decides whether to allow a new FA-device to join the FA-system, the new FA-device can only join the FA-system if it gets the certificate issued by the registry for it, if the registry is not available, the means for replacing the registry needs to get the key of the Registrar if it issues the certificate for the new FA-device using other means, such as a debugging tool, instead of the registry, which is extremely insecure.
According to the technical scheme, under the condition that the registry is unavailable, the second device can replace the first device by obtaining the private key and the first certificate of the first device, and does not need to replace a register to issue the certificate for the second device, so that the problem that other devices obtain the private key of the registry in order to issue the certificate of the second device is solved, the private key of the registry is guaranteed to be only stored in the registry, and the safety of the whole system is improved to a great extent.
The first certificate may be before the first device is undamaged and the registry is available, the registry being issued by the first device, and the first device may join the FA-system through the first certificate. For example, the first certificate may be an LDevID certificate. The first certificate may include public key information of the first device, a name of the first device, and a signature of the registry. In addition, the first certificate may further include information such as a serial number of the first device, a name of the registry, and a validity period of the first certificate.
The second private key is obtained by encrypting the private key of the first device by the public key of the hardware device before the first device is damaged. Before the first device encrypts its private key, the first device may first obtain the public key of the hardware device. For example, the hardware device may broadcast its public key to all devices, so that the first device may obtain the public key of the hardware device. For another example, the hardware device may send its public key to the debug tool, and the debug tool receives the public key of the hardware device and forwards the public key to the first device. For example, the debugging tool may bear the public key of the hardware device in the first registration request message when sending the first registration request message to device a in step 110 of fig. 1. As another example, the debug tool may send the public key of the hardware device to device a at step 170 in fig. 1 while the debug tool forwards the registration response message to device a.
When the first device encrypts its private key, the first device may encrypt its private key using an asymmetric encryption algorithm. The asymmetric encryption algorithm means that if data is encrypted with a public key, the encrypted data can be decrypted only with a corresponding private key. The asymmetric encryption algorithm herein may include, but is not limited to, RSA algorithm, elliptic Curve Cryptography (ECC) algorithm, knapsack algorithm, rabin algorithm, or Diffie-Hellman Key Exchange (D-H) algorithm, etc.
The first device encrypts the private key of the hardware device by using the public key of the hardware device through the asymmetric encryption algorithm, so that the security of the private key of the first device can be improved, and the attack of malicious devices can be prevented.
After the first device encrypts its private key to obtain a second private key, the first device may send the second private key to the debugging tool, and then the debugging tool may store the second private key. In addition, the first device may also send the first certificate to a commissioning tool. Similar to the second private key, the debug tool may also store the first certificate.
Optionally, the debugging tool may store the second private key and/or the first certificate in the cloud, or may store the second private key and/or the first certificate in its own security module or other module.
The second private key and/or the first certificate are/is stored in the debugging tool, and the private key of the hardware device for decrypting the second private key is only stored in the hardware device, so that the problem that the second private key, the first certificate and the private key of the hardware device are stored in the same device is solved, and the security of the private key of the first device is further improved.
After the registry is unavailable and the first device is damaged, the second device needs to acquire the private key and the first certificate of the first device, so that the second device can perform subsequent operations according to the private key and the first certificate of the first device instead of the first device, for example, data transmission between the first device and other devices is replaced.
In order to avoid that devices other than the second device also acquire the private key and the first certificate of the first device and ensure the security of the private key and the first certificate of the first device, the debugging tool may acquire the mapping relationship between the first device and the second device, so as to communicate with the second device based on the mapping relationship.
As an example, a debugging tool may establish a mapping relationship. Optionally, the debugging tool may establish a mapping relationship according to the attribute information of the first device and the attribute information of the second device. The attribute information of the first device may be, but is not limited to, a serial number of the device, a Media Access Control (MAC) address of the device, identification information of the device, and the like.
Alternatively, the attribute information of the first device and the attribute information of the second device may be preset on the commissioning tool. It should be noted that, in addition to the first device and the second device, the debugging tool may have attribute information of a plurality of devices in advance.
Alternatively, the attribute information of the first device may be that the first device is sent to the debugging tool before being damaged, and the attribute information of the second device may be that the administrator configures the debugging tool, for example.
As another example, the mapping relationship between the first device and the second device may be configured on a commissioning tool by a user, such as an administrator. For example, the administrator may configure a mapping relationship between the first device and the second device on the commissioning tool according to the attribute information of the first device and the attribute information of the second device.
According to the technical scheme, the serial number and the MAC address of the equipment can be the parameters which can reflect the identity of the equipment most, so that the mapping relation between the first equipment and the second equipment determined according to the serial number and/or the MAC address can be effectively distinguished from other equipment.
In order to enable the second device to obtain the private key and the first certificate of the first device, optionally, the debugging tool may first obtain a second certificate of the second device, where the second certificate is a certificate issued by the manufacturer for the second device, that is, a certificate issued by the manufacturer for the second device when the second device leaves a factory. The second certificate may include information such as public key information of the second device, a name of the second device, and a serial number of the second device. As an example, the second certificate may be an IDevID certificate.
Optionally, the debug tool may establish a Transport Layer Security (TLS) connection with the second device, and receive, through the TLS connection, the second certificate sent by the second device.
In order to guarantee the accuracy of the second certificate, i.e. to guarantee that the second certificate is a certificate of the second device, further the commissioning tool may verify the second certificate. Specifically, the debugging tool may verify the second certificate according to the mapping relationship. For example, the commissioning tool may compare the serial number in the second certificate with the serial number of the second device in the mapping, and if the serial number in the second certificate is the same as the serial number of the second device in the mapping, it may be determined that the received second certificate is the certificate of the second device.
Or, the debugging tool may compare the obtained public key of the second device with the public key in the second certificate, and if the obtained public key of the second device is the same as the public key in the second certificate, the debugging tool may determine that the received second certificate is the certificate of the second device.
After the second certificate is acquired by the debugging tool, optionally, the debugging tool may store the second certificate in the cloud. If the second private key is also stored in the cloud, the hardware device may obtain the second certificate and the second private key from the cloud. Alternatively, the debug tool may send the second certificate and the previously stored second private key to the hardware device. The hardware device and the debugging tool may communicate with each other through, but not limited to, a USB protocol, for example, the debugging tool may send the second certificate and the second private key to the hardware device through the USB protocol.
And after the hardware equipment acquires the second private key, the hardware equipment decrypts the second private key by adopting the private key of the hardware equipment to obtain the private key of the first equipment. And then, the hardware device encrypts the private key of the first device by using the public key of the second device in the second certificate to obtain a first private key. Likewise, the hardware device may encrypt the private key of the first device using an asymmetric encryption algorithm to ensure the security of the private key of the first device.
Next, the hardware device may send the first private key to a debugging tool. And after receiving the first private key, the debugging tool sends the first private key and the previously stored first certificate to the second device. The debugging tool may send the first private key and the first certificate to the second device at the same time, or send the first private key and the first certificate to the second device in a time-sharing manner, which is not specifically limited in this embodiment of the application.
After receiving the first private key and the first certificate, the second device can decrypt the first private key by using the private key of the second device to obtain the private key of the first device. The second device may then join the system using the first device's private key and first certificate to perform operations in place of the first device.
In order to more clearly understand the methods 200-500 for device replacement according to the embodiments of the present application, a method 600 for device replacement according to one possible embodiment of the present application is described below with reference to fig. 6.
In 601, the commissioning tool sends a third registration request message to the first device, the third registration request message indicating that the first device requests to access the FA-system, and the third registration request message including the public key of the hardware device.
In 602, a first device generates a key pair comprising a public key and a private key.
In 603, the first device sends a fourth registration request message to the commissioning tool.
And the fourth registration request message is corresponding to the third registration request message and is used for indicating the equipment to request to access the FA-system.
At 604, the debug tool forwards the fourth registration request message to the Registrar.
At 605, registrar issues a first certificate for the first device.
The registry may validate the fourth registration request message before issuing the first certificate. If it is determined that the fourth registration request was sent by the first device, the registry may issue the first certificate for the first device.
At 606, the registry sends a second registration request response message to the debug tool, the second registration request response message including the first certificate.
In 607, the debug tool saves the first certificate.
At 608, the debug tool forwards the second registration request response message to the first device.
In 609, the first device extracts the first certificate from the second registration request response message, and encrypts a private key of the first certificate to obtain a second private key.
Wherein the first device may encrypt its private key with the public key of the hardware device received in 601.
In 610, the first device sends the second private key to the commissioning tool.
At 611, the debug tool saves the second private key.
At 612, the first device joins the FA-system and begins operating.
In 613, registrar is not available.
For example, registrar is in a sleep state, or Registrar is damaged.
At 614, the first device is damaged and needs to be replaced in a short amount of time.
At 615, the commissioning tool establishes a mapping relationship between the first device and the second device.
Optionally, the debugging tool may establish a mapping relationship according to the attribute information of the first device and the attribute information of the second device. The attribute information may include a sequence number, a MAC address, and the like.
In 616, the second device sends the second certificate to the commissioning tool.
The debug tool may first establish a TLS connection with the second device, and the second device sends the second certificate to the debug tool through the TLS connection.
At 617, the debug tool validates the second certificate against the mapping.
For example, the commissioning tool may compare the serial number of the second device in the mapping relationship with the serial number in the second certificate, and if the serial number and the serial number are the same, the second certificate is the certificate of the second device.
At 618, the debug tool sends the second certificate and the second private key to the hardware device.
Wherein the second certificate comprises the public key of the second device.
At 619, the hardware device decrypts and encrypts the second private key to obtain the first private key.
Specifically, the hardware device decrypts the second private key by using the private key thereof to obtain the private key of the first device, and encrypts the private key of the first device by using the public key of the second device to obtain the first private key.
At 620, the hardware device sends the first private key to the debugging tool.
At 621, the debug tool sends the first private key and the first certificate to the second device.
At 622, the second device decrypts the first private key.
Specifically, the second device decrypts the first private key by using its own private key, so as to obtain the private key of the first device.
In 623, the second device joins the FA-system in place of the first device based on the first certificate and the private key of the first device.
It should be understood that, in the embodiments of the present application, the terms "first", "second", "third" and "fourth" are merely used to distinguish different objects, and do not limit the scope of the embodiments of the present application.
According to the embodiment of the application, under the condition that the second device needs to replace the first device, after the debugging tool obtains the first certificate and the first private key of the first device, the first certificate and the first private key are forwarded to the second device, so that the second device can obtain the private key of the first device based on the first private key and replace the first device based on the private key of the first device and the first certificate of the first device. According to the technical scheme, the certificate does not need to be issued to the second device, and parameters such as the serial number do not need to be configured for the second device again, so that the purpose that the second device replaces the first device can be achieved in a short time, and the processing speed is effectively improved.
Further, the embodiment of the application realizes the encryption and decryption of the private key of the first device by introducing the hardware device and utilizing the public key and the private key generated by the hardware device. The private key of the hardware device for decryption is only stored in the hardware device, and the private key of the hardware device cannot be extracted from the hardware device by other devices, so that the security of the private key of the first device is improved, and the attack of malicious devices is prevented.
The method embodiments of the present application are described above in detail, and the apparatus embodiments of the present application are described below, and the apparatus embodiments and the method embodiments correspond to each other, so that the parts that are not described in detail can be referred to the foregoing method embodiments, and the apparatus can implement any possible implementation manner of the above method.
FIG. 7 shows a schematic block diagram of a debugging tool 700 of one embodiment of the present application. The commissioning tool 700 may perform the method 200 for device replacement according to the embodiment of the present application, and the commissioning tool 700 may be a commissioning tool of the foregoing methods.
As shown in fig. 7, the debugging tool 700 includes:
an obtaining unit 710, configured to obtain a first certificate and a first private key of a first device, where the first private key is obtained by encrypting, by a hardware device, a private key of the first device by using a public key of a second device, the hardware device is configured to encrypt and decrypt a key, the second device is a replacement device of the first device, and the first certificate is used for accessing, by the first device, to an internet of things system before the second device replaces the first device;
a communication unit 720, configured to send the first private key and the first certificate to the second device, where the first private key is used for the second device to obtain the private key of the first device, and the private key of the first device and the first certificate are used for the second device to replace the first device.
Optionally, in an embodiment of the present application, the obtaining unit 710 is further configured to: acquiring a second private key and a second certificate of the second device, where the second certificate is a certificate issued by a manufacturer for the second device and includes a public key of the second device, and the second private key is obtained by encrypting, by the first device, the private key of the first device with the public key of the hardware device;
the communication unit 720 is further configured to: and sending the second private key and the second certificate to the hardware device, and receiving the first private key sent by the hardware device.
Optionally, in an embodiment of the present application, the communication unit 720 is further configured to: receiving a second private key sent by the first device;
the commissioning tool 700 further comprises: a storage unit for storing the second private key.
Optionally, in an embodiment of the present application, the obtaining unit 710 is specifically configured to: establishing a transport layer security, TLS, connection with the second device;
the communication unit 720 is further configured to: receiving the second certificate sent by the second device through the TLS connection.
Optionally, in an embodiment of the present application, the obtaining unit 710 is further configured to: establishing the mapping relation according to the attribute information of the first device and the attribute information of the second device, wherein the attribute information comprises a serial number and/or a Media Access Control (MAC) address;
the commissioning tool 700 further comprises: and the verification unit is used for verifying the second certificate according to the mapping relation.
Optionally, in an embodiment of the present application, the communication unit 720 is further configured to: receiving a public key of the hardware device sent by the hardware device; sending the public key of the hardware device to the first device.
Optionally, in an embodiment of the present application, the first certificate is a certificate issued by the registrar to the first device if the first certificate is available, and the communication unit 720 is further configured to: receiving the first certificate sent by the registrar;
the storage unit is further configured to: storing the first certificate;
the obtaining unit 710 is specifically configured to: the debug tool obtains the first private key when the registrar is unavailable.
Fig. 8 shows a schematic block diagram of a hardware device 800 of an embodiment of the present application. The hardware device 800 may execute the method 300 for device replacement according to the embodiment of the present application, and the hardware device 800 may be a hardware device in the foregoing method.
As shown in fig. 8, the hardware device 800 includes:
a communication unit 810, configured to receive a second private key sent by a debugging tool, where the second private key is obtained by encrypting, by the first device, a private key of the first device with a public key of the hardware device;
a decryption unit 820, configured to decrypt the second private key with the private key of the hardware device to obtain the private key of the first device;
an encrypting unit 830, configured to encrypt a private key of a first device with a public key of a second device to obtain a first private key, where the second device is a replacement device of the first device;
the communication unit 810 is further configured to send the first private key to the debugging tool, where the first private key is used by the second device to obtain the private key of the first device.
Optionally, in an embodiment of the present application, the communication unit 810 is further configured to: receiving a second certificate of the second device sent by the commissioning tool, the second certificate being a certificate issued by a manufacturer for the second device and including a public key of the second device.
Optionally, in an embodiment of the present application, the communication unit 810 is further configured to: the hardware device sends the public key of the hardware device to the debugging tool.
Fig. 9 shows a schematic block diagram of an apparatus 900 for device replacement of one embodiment of the present application. The apparatus 900 for device replacement may perform the method 400 for device replacement of the embodiment of the present application, and the apparatus 900 for device replacement may be a second device in the foregoing methods.
As shown in fig. 9, the apparatus 900 for replacing may include:
an obtaining unit 910, configured to obtain a first certificate of a first device and a private key of the first device, where the first certificate is used for the first device to access an internet of things system before the second device replaces the first device;
a processing unit 920, configured to replace the first device based on the first certificate and a private key of the first device.
Optionally, in an embodiment of the present application, the apparatus 900 for device replacement may further include a communication unit, configured to receive a first private key sent by the debugging tool, where the first private key is obtained by encrypting, by a hardware device, a private key of a first device with a public key of a second device;
the apparatus 900 for device replacement may further include a decryption unit, configured to decrypt the first private key with the private key of the second device, so as to obtain the private key of the second device.
Optionally, in an embodiment of the present application, the communication unit is further configured to: sending a second certificate of the second device to a commissioning tool over a transport layer security, TLS, connection, the second certificate being a certificate issued by a manufacturer for the second device and comprising a public key of the second device.
Optionally, in an embodiment of the present application, the first certificate is a certificate issued by the registrar to the first device if available, and the communication unit is further configured to: receiving the first certificate sent by a debugging tool when the registrar is not available.
Fig. 10 shows a schematic block diagram of an apparatus 1000 for device replacement of another embodiment of the present application. The apparatus 1000 for replacing a device may perform the method 500 for replacing a device according to the embodiment of the present application, and the apparatus 1000 for replacing a device may be the first device in the foregoing methods.
As shown in fig. 10, the apparatus 1000 of the device replacement may include:
an acquisition unit 1010 configured to acquire a public key of a hardware device;
an encrypting unit 1020, configured to encrypt the private key of the first device with the public key of the hardware device to obtain a second private key;
a communication unit 1030 configured to send, to a commissioning tool, the second private key and a first certificate of the first device, where the first certificate is used for the first device to access an internet of things system before a second device replaces the first device, and for the second device to replace the first device.
Fig. 11 is a hardware configuration diagram of an apparatus according to an embodiment of the present application. The apparatus 1100 shown in fig. 11 may be a debugging tool, a hardware device, or a device replacement apparatus, and the apparatus 1100 includes a memory 1101, a processor 1102, a communication interface 1103, and a bus 1104. The memory 1101, the processor 1102 and the communication interface 1103 are communicatively connected to each other by a bus 1104.
The memory 1101 may be read-only memory (ROM), static storage device, and Random Access Memory (RAM). The memory 1101 may store programs, and when the programs stored in the memory 1101 are executed by the processor 1102, the processor 1102 and the communication interface 1103 are used for executing the steps of the method for device replacement of the embodiment of the present application.
The processor 1102 may be a general-purpose Central Processing Unit (CPU), a microprocessor, an Application Specific Integrated Circuit (ASIC), a Graphics Processing Unit (GPU), or one or more integrated circuits, and is configured to execute related programs to implement the functions that the units in the apparatus according to the embodiment of the present disclosure need to execute, or to execute the method for replacing the apparatus according to the embodiment of the present disclosure.
The processor 1102 may also be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the method for device replacement according to the embodiment of the present application may be implemented by instructions in the form of hardware integrated logic circuits or software in the processor 1102.
The processor 1102 may also be a general purpose processor, a Digital Signal Processor (DSP), an ASIC, an FPGA (field programmable gate array) or other programmable logic device, discrete gate or transistor logic, or discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in a processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in the memory 1101, and the processor 1102 reads the information in the memory 1101, and completes the functions required to be performed by the units included in the apparatus according to the embodiment of the present application, or performs the method for device replacement according to the embodiment of the present application, in combination with hardware thereof.
The communication interface 1103 enables communication between the apparatus 1100 and other devices or communication networks using transceiver means, such as, but not limited to, a transceiver. For example, when the apparatus 1100 is a debugging tool, the first private key and the first certificate may be sent to the second device through the communication interface 1103.
Bus 1104 may include a path that conveys information between various components of apparatus 1100 (e.g., memory 1101, processor 1102, communication interface 1103).
It should be noted that although the apparatus 1100 described above shows only memories, processors, and communication interfaces, in a particular implementation, those skilled in the art will appreciate that the apparatus 1100 may also include other components necessary to achieve proper operation. Also, those skilled in the art will appreciate that the apparatus 1100 may also include hardware components for performing other additional functions, according to particular needs. Further, those skilled in the art will appreciate that apparatus 1100 may also include only those components necessary to implement embodiments of the present application, and need not include all of the components shown in FIG. 11.
The embodiment of the application also provides a computer readable storage medium for storing a program code for equipment execution, wherein the program code comprises instructions for executing the steps in the method for equipment replacement.
Embodiments of the present application also provide a computer program product, which includes a computer program stored on a computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the above-mentioned device replacement method.
The computer-readable storage medium described above may be a transitory computer-readable storage medium or a non-transitory computer-readable storage medium.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working process of the apparatus described above may refer to the corresponding process in the foregoing method embodiment, and is not described herein again.
In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The words used in this application are words of description only and not of limitation of the claims. As used in the description of the embodiments and the claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Similarly, the term "and/or" as used in this application is meant to encompass any and all possible combinations of one or more of the associated listed. In addition, the terms "comprises" and/or "comprising," when used in this application, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The various aspects, implementations, or features of the described embodiments can be used alone or in any combination. Aspects of the described embodiments may be implemented by software, hardware, or a combination of software and hardware. The described embodiments may also be embodied by a computer-readable medium having computer-readable code stored thereon, the computer-readable code comprising instructions executable by at least one computing device. The computer readable medium can be associated with any data storage device that can store data which can be read by a computer system. Exemplary computer-readable media can include read-only memory, random-access memory, compact disk read-only memory (CD-ROM), hard Disk Drive (HDD), digital Video Disk (DVD), magnetic tape, and optical data storage devices. The computer readable medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.
The above description of the technology may refer to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration embodiments in which the described embodiments may be practiced. While these embodiments are described in sufficient detail to enable those skilled in the art to practice them, they are not limiting; other embodiments may be utilized and changes may be made without departing from the scope of the described embodiments. For example, the order of operations described in a flowchart is non-limiting, and thus the order of two or more operations illustrated in and described in accordance with the flowchart may be altered in accordance with several embodiments. As another example, in several embodiments, one or more operations illustrated in and described with respect to the flowcharts are optional or may be eliminated. Additionally, certain steps or functions may be added to the disclosed embodiments, or two or more steps may be permuted in order. All such variations are considered to be encompassed by the disclosed embodiments and the claims.
Additionally, terminology is used in the foregoing description of the technology to provide a thorough understanding of the described embodiments. However, no unnecessary detail is required to implement the described embodiments. Accordingly, the foregoing description of the embodiments has been presented for purposes of illustration and description. The embodiments presented in the foregoing description and the examples disclosed in accordance with these embodiments are provided solely to add context and aid in the understanding of the described embodiments. The above description is not intended to be exhaustive or to limit the described embodiments to the precise form disclosed. Many modifications, alternative uses, and variations are possible in light of the above teaching. In some instances, well known process steps have not been described in detail in order to avoid unnecessarily obscuring the described embodiments.
The above description is only a specific implementation of the embodiments of the present application, but the scope of the embodiments of the present application is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the embodiments of the present application, and all the changes or substitutions should be covered by the scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application shall be subject to the protection scope of the claims.

Claims (21)

1. A method of device replacement, comprising:
a debugging tool obtains (210) a first certificate and a first private key of a first device, wherein the first private key is obtained by encrypting the private key of the first device by a hardware device by adopting a public key of a second device, the hardware device is used for encrypting and decrypting the key, the second device is a replacement device of the first device, and the first certificate is used for accessing the first device into an Internet of things system before the second device replaces the first device;
the commissioning tool sends (220) the first private key and the first certificate to the second device, the first private key being used by the second device to obtain the private key of the first device, the private key of the first device and the first certificate being used by the second device to replace the first device.
2. The method of claim 1, further comprising:
the debugging tool acquires a second private key and a second certificate of the second device, wherein the second certificate is a certificate issued by a manufacturer for the second device and comprises a public key of the second device, and the second private key is obtained by encrypting the private key of the first device by using the public key of the hardware device;
the debugging tool sending the second private key and the second certificate to the hardware device;
the debugging tool obtains (210) a first private key, comprising:
the debugging tool receives the first private key sent by the hardware device.
3. The method of claim 2, wherein the debugging tool obtaining the second private key comprises:
the debugging tool receives a second private key sent by the first device;
the debug tool stores the second private key.
4. The method of claim 2 or 3, wherein the debugging tool obtaining the second certificate of the first device comprises:
the debugging tool establishes a Transport Layer Security (TLS) connection with the second device;
and the debugging tool receives the second certificate sent by the second equipment through the TLS connection.
5. The method of claim 4, further comprising:
the debugging tool establishes the mapping relation according to the attribute information of the first equipment and the attribute information of the second equipment, wherein the attribute information comprises a serial number and/or a Media Access Control (MAC) address;
and the debugging tool verifies the second certificate according to the mapping relation.
6. The method according to any one of claims 1 to 5, further comprising:
the debugging tool receives a public key of the hardware device sent by the hardware device;
the debug tool sends the public key of the hardware device to the first device.
7. The method according to any one of claims 1 to 6, wherein the first certificate is a certificate that a registrar issued to the first device if available;
the commissioning tool obtaining (210) a first certificate for a first device, comprising:
the debugging tool receives the first certificate sent by the register;
the commissioning tool storing the first certificate;
the debugging tool obtains (210) a first private key, comprising:
the debug tool obtains the first private key when the registrar is unavailable.
8. A method of device replacement, comprising:
a hardware device receives (310) a second private key sent by a debugging tool, wherein the second private key is obtained by encrypting a private key of the first device by using a public key of the hardware device;
the hardware device decrypts (320) the second private key by using the private key of the hardware device to obtain the private key of the first device;
the hardware device encrypts (330) a private key of the first device by using a public key of a second device to obtain a first private key, wherein the second device is a replacement device of the first device;
the hardware device sends (340) the first private key to the commissioning tool, the first private key being used by the second device to obtain the private key of the first device.
9. The method of claim 8, further comprising:
the hardware device receives a second certificate of the second device sent by the debugging tool, wherein the second certificate is a certificate issued by a manufacturer for the second device and comprises a public key of the second device.
10. The method according to claim 8 or 9, characterized in that the method further comprises:
the hardware device sends a public key of the hardware device to the debug tool.
11. A method of device replacement, comprising:
a second device obtaining (410) a first certificate of a first device and a private key of the first device, the first certificate being used for the first device to access an internet of things system before the second device replaces the first device;
the second device replaces (420) the first device based on the first certificate and the private key of the first device.
12. The method of claim 11, wherein the second device obtaining (410) the private key of the first device comprises:
the second device receives a first private key sent by a debugging tool, wherein the first private key is obtained by encrypting the private key of the first device by the hardware device by adopting a public key of the second device;
and the second equipment decrypts the first private key by adopting the private key of the second equipment to obtain the private key of the second equipment.
13. The method of claim 12, further comprising:
and the second device is connected through a Transport Layer Security (TLS), and sends a second certificate of the second device to a debugging tool, wherein the second certificate is a certificate issued by a manufacturer for the second device and comprises a public key of the second device.
14. A method according to any one of claims 11 to 13, wherein a first certificate is a certificate which a registrar issues to the first device if available;
the second device obtaining (410) a first certificate of the first device, comprising:
when the registrar is not available, the second device receives the first certificate sent by a commissioning tool.
15. A method of device replacement, comprising:
the first device obtains (510) a public key of the hardware device;
the first device encrypts (520) the private key of the first device with the public key of the hardware device to obtain a second private key;
the first device sends (530) the second private key and a first certificate of the first device to a commissioning tool, the first certificate for the first device to access an internet of things system and for the second device to replace the first device before the second device replaces the first device.
16. A debugging tool, comprising:
an obtaining unit (710) configured to obtain a first certificate and a first private key of a first device, where the first private key is obtained by encrypting, by a hardware device, a private key of the first device using a public key of a second device, the hardware device is configured to encrypt and decrypt the private key of the first device, the second device is a replacement device of the first device, and the first certificate is used for accessing, by the first device, to an internet of things system before the second device replaces the first device;
a communication unit (720) configured to send the first private key and the first certificate to the second device, where the first private key is used by the second device to obtain a private key of the first device, and the private key of the first device and the first certificate are used by the second device to replace the first device.
17. A hardware device, comprising:
a communication unit (810) configured to receive a second private key sent by a debugging tool, where the second private key is obtained by encrypting, by the first device, a private key of the first device with a public key of the hardware device;
a decryption unit (820) configured to decrypt the second private key with the private key of the hardware device to obtain the private key of the first device;
an encryption unit (830) configured to encrypt a private key of a first device with a public key of a second device to obtain a first private key, where the second device is a replacement device of the first device;
the communication unit (810) is further configured to send the first private key to the commissioning tool, where the first private key is used for the second device to obtain the private key of the first device.
18. An apparatus for device replacement, wherein the apparatus is a second device, comprising:
an obtaining unit (910) configured to obtain a first certificate of a first device and a private key of the first device, where the first certificate is used for the first device to access an internet of things system before the second device replaces the first device;
a processing unit (920) for replacing the first device based on the first certificate and a private key of the first device.
19. An apparatus for device replacement, the apparatus being a first device, comprising:
an acquisition unit (1010) for acquiring a public key of a hardware device;
an encrypting unit (1020) configured to encrypt the private key of the first device with the public key of the hardware device to obtain a second private key;
a communication unit (1030) configured to send the second private key and a first certificate of the first device to a commissioning tool, the first certificate being used for the first device to access an internet of things system and for the second device to replace the first device before the second device replaces the first device.
20. An apparatus, comprising:
a memory for storing a program;
a processor for executing the memory-stored program, the processor for performing the method of device replacement according to any one of claims 1 to 15 when the memory-stored program is executed.
21. A computer-readable storage medium, characterized in that the computer-readable medium stores program code for device execution, the program code comprising instructions for performing the steps in the method of device replacement according to any one of claims 1 to 15.
CN202111005965.6A 2021-08-30 2021-08-30 Method for replacing equipment, debugging tool, hardware equipment and device Pending CN115730352A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111005965.6A CN115730352A (en) 2021-08-30 2021-08-30 Method for replacing equipment, debugging tool, hardware equipment and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111005965.6A CN115730352A (en) 2021-08-30 2021-08-30 Method for replacing equipment, debugging tool, hardware equipment and device

Publications (1)

Publication Number Publication Date
CN115730352A true CN115730352A (en) 2023-03-03

Family

ID=85290980

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111005965.6A Pending CN115730352A (en) 2021-08-30 2021-08-30 Method for replacing equipment, debugging tool, hardware equipment and device

Country Status (1)

Country Link
CN (1) CN115730352A (en)

Similar Documents

Publication Publication Date Title
US10003582B2 (en) Technologies for synchronizing and restoring reference templates
ES2922726T3 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
US20200162247A1 (en) Secure firmware transfer from a server to a primary platform
US10958664B2 (en) Method of performing integrity verification between client and server and encryption security protocol-based communication method of supporting integrity verification between client and server
US10009760B2 (en) Providing network credentials
WO2016011778A1 (en) Data processing method and apparatus
JP6096785B2 (en) Method for transferring control of a security module from a first entity to a second entity
JP2012104135A (en) Device, method and storage medium utilizing device identifier
US9904806B2 (en) Hardware security module, method of updating integrity check value stored in hardware security module, and method of updating program stored in terminal by using hardware security module
CN110995759A (en) Access method and device of Internet of things
US20220209944A1 (en) Secure Server Digital Signature Generation For Post-Quantum Cryptography Key Encapsulations
TW201638822A (en) Method and device for identity authentication of process
JP2022109301A (en) Data transmission method, communication processing method, apparatus, and communication processing program
WO2019120231A1 (en) Method and device for determining trust state of tpm, and storage medium
US20210126776A1 (en) Technologies for establishing device locality
WO2022116209A1 (en) Internet of things device access authentication method and apparatus, device, and storage medium
WO2020216047A1 (en) Authentication information processing method, terminal, and network device
KR101711023B1 (en) Security device and method moving data using the same
CN110912685A (en) Establishing a protected communication channel
CN115730352A (en) Method for replacing equipment, debugging tool, hardware equipment and device
JP6527115B2 (en) Device list creating system and device list creating method
WO2018172776A1 (en) Secure transfer of data between internet of things devices
WO2018076299A1 (en) Data transmission method and device
CN110858246B (en) Authentication method and system of security code space, and registration method thereof
EP3361696B1 (en) A method for securely exchanging link discovery information

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination