WO2023092563A1 - 远程控制的方法和装置 - Google Patents

远程控制的方法和装置 Download PDF

Info

Publication number
WO2023092563A1
WO2023092563A1 PCT/CN2021/134045 CN2021134045W WO2023092563A1 WO 2023092563 A1 WO2023092563 A1 WO 2023092563A1 CN 2021134045 W CN2021134045 W CN 2021134045W WO 2023092563 A1 WO2023092563 A1 WO 2023092563A1
Authority
WO
WIPO (PCT)
Prior art keywords
whitelist
authorization token
remote control
signature
token
Prior art date
Application number
PCT/CN2021/134045
Other languages
English (en)
French (fr)
Inventor
许正磊
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2021/134045 priority Critical patent/WO2023092563A1/zh
Priority to CN202180104413.2A priority patent/CN118235366A/zh
Publication of WO2023092563A1 publication Critical patent/WO2023092563A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • the embodiments of the present application relate to the field of remote control, and more specifically, to a method and device for identity authentication and authentication in the process of remote control.
  • the terminal can send remote control instructions to remote devices (such as smart vehicles, smart homes, etc.) through the device management system deployed in the cloud, thereby realizing intelligent control of devices and making remote control more comfortable and convenient .
  • remote devices such as smart vehicles, smart homes, etc.
  • the remote device In the process of realizing the intelligent control of equipment, higher requirements are put forward for the security of the remote control system.
  • the remote device only verifies the device management system, but cannot directly verify the identity and operation intention of the operator (user). Once the device management system is attacked or the operation and maintenance personnel do not comply with the regulations, The remote device is attacked through the device management system, resulting in violation of the user's privacy, property and life safety.
  • the embodiment of the present application provides a remote control method and device. After the end user issues an authorization token, the remote device verifies the received authorization token and remote control instructions, and verifies whether the remote control instructions are issued or authorized by a legal user. Whether it is within the scope of the authorization token to ensure that the remote control command is authorized by the user, reducing the risk of user privacy disclosure and property loss.
  • a remote control method comprising: a remote device receives second request information from a device management system, the second request information includes a remote control instruction and an authorization token; the remote device verifies the authorization token validity; the remote device uses the authorization token to verify the legitimacy of the remote control command when the authorization token is valid.
  • the authorization token content includes: at least one of token ID, issuer ID, authorized object ID, authorized content list, issuance time, validity period start time, and validity period end time; the authorized content list includes: controlled At least one of object identification, operation, and key parameters; the authorization token signature information includes signature data, or the authorization token signature information includes signature data and a signature algorithm.
  • the content and signature of the authorization token can be changed according to actual needs, for example, the authorization token can be composed of part of all the contents of the authorization token.
  • the authorization token signature may only contain signature data.
  • the authorization token can be attached with additional encryption measures such as secondary token signature and so on.
  • the generated authorization token can flexibly adjust the content of the authorization token according to actual needs to adapt to different application scenarios of the authorization token.
  • the generated authorization token can be signed and/or encrypted. Secure the use of authorization tokens.
  • verifying the validity of the authorization token includes at least one of the following: verifying whether the device management system is consistent with the authorized object ID, verifying whether the controlled object ID is consistent with the remote device ID, verifying the time validity of the token, Verify whether the signature verification key of the token issuer has been configured on the remote device, and verify whether the digital signature of the authorization token is consistent.
  • verifying the legitimacy of the remote command includes at least one of the following: verifying whether the remote device identifier is consistent with the controlled object identifier in the authorization token, verifying whether the remote control instruction is within the allowed operating range of the authorization token, verifying Whether the key parameter is within the key parameter range of the authorization token.
  • the remote device can verify the validity of the received authorization token, and use the authorization token to verify the legitimacy of the remote control command after the validity verification is passed.
  • the device executes the remote control command. In this way, it can be ensured that the remote control instructions are consistent with the intention of the device owner/authorizer, reducing the risk of user privacy leakage and property loss.
  • a user can directly or indirectly send commands to a remote device through a device management system to control the operation of the remote device.
  • the remote device since the remote device only authenticates the equipment management system, it cannot directly verify the identity and operation intention of the operator (user), in other words, the remote device cannot confirm the received remote control Whether the command is authorized by the user.
  • the remote device Once the device management system is attacked or the operation and maintenance personnel do not comply with the regulations, the remote device may be attacked, causing the user's privacy, property and life safety to be violated.
  • a device management system may be attacked by hackers.
  • hackers invade the device management system to steal and tamper with the user's remote control instructions. Since the remote device cannot identify whether the remote control instruction is authorized by the user, once the remote device executes the remote control instruction tampered with by the hacker, the user's property will be damaged.
  • the operation and maintenance personnel of the equipment management system may cause remote control instructions not in line with the user's operation intention due to operations beyond the scope of their duties. Remote control instructions that do not conform to the user's operation intention will make the user's privacy and property safety not guaranteed.
  • the embodiment of this application adopts the method of transmitting the remote control instruction and the authorization token together. After the remote device receives the remote control instruction and the authorization token, it needs to use the authorization token to verify the remote control instruction to verify whether the remote control instruction is authorized. To ensure that the remote control command is authorized by the user, and avoid the threat to the security of the remote device caused by the operation and maintenance personnel's unlawful operation.
  • the second request information further includes a whitelist
  • the verifying the validity of the authorization token further includes: verifying whether the authorization token ID is in the whitelist ID list .
  • the second request information further includes a blacklist
  • the verifying the validity of the authorization token further includes: verifying whether the authorization token ID is in the blacklist ID list .
  • the authorization token when the remote control involves a long-term task, the characteristic of the long-term task is that the task may be canceled.
  • the authorization token also needs to be revoked synchronously, which requires a mechanism to ensure that the revoked authorization token is not Illegal use.
  • the whitelist scheme can also be replaced by a blacklist scheme, and the tokens that have been revoked are listed in the blacklist to ensure Authorization tokens are secure to use.
  • the whitelist can be released while signing the authorization token, and then judge whether the authorization token ID is in the whitelist ID list after the authorization token is verified, so as to ensure that the authorization token is not revoked.
  • Authorization tokens can only be used if they pass the whitelist verification. It is also possible to publish the blacklist while signing the authorization token, and judge whether the authorization token ID is in the blacklist ID list on the basis of the authorization token verification. The authorization token ID can only be used if it is not in the blacklist list. . Through the above method, it can be guaranteed that the authorization token has not been revoked, reducing the risk of user's privacy leakage and property loss.
  • the method further includes: the remote device verifies the validity of the whitelist.
  • the validity of the whitelist can be verified while the whitelist is released. Only when the whitelist is valid, the whitelist is used to verify the validity of the authorization token, which can ensure the safe use of the whitelist and reduce the risk of user privacy disclosure and property loss.
  • verifying the validity of the whitelist includes at least one of the following: verifying the consistency between the remote device identifier and the controlled object identifier in the whitelist, verifying the issuance time of the whitelist Whether it is less than or equal to the first threshold, verify the consistency of the whitelist signature.
  • verifying whether the whitelist issuance time is less than or equal to the first threshold may refer to judging whether the whitelist issuance time is within the allowable range of the current time difference of the remote device system.
  • the first threshold represents the maximum value allowed by the current time difference of the remote device system, and its value can be preset according to the actual situation.
  • the allowable range of the current time difference of the remote device system is set to be within 10 seconds, and when the whitelist issuance time is 8 seconds, the whitelist issuance time meets the requirements. When the whitelist issuance time is 12 seconds, the whitelist issuance time does not meet the requirement, and the whitelist update fails.
  • Verifying the consistency of the whitelist signature can refer to using the key to verify the validity of the whitelist signature. If the whitelist signature is consistent with the key, the signature verification is successful; if the whitelist signature is inconsistent with the key, the signature verification fails. Whitelist update failed.
  • the validity verification of the released white list can be carried out by verifying the consistency between the controlled object in the white list and the identity of the remote device, verifying the white list, verifying whether the white list issuance time is less than or equal to the first threshold, and verifying the white list
  • the consistency of the signature ensures that the whitelist will not be attacked, which can reduce the risk of users' privacy leakage and property loss.
  • the method further includes: the remote device determines a whitelist characteristic value according to the whitelist; the remote device signs and/or Encryption: the remote device sends the signed and/or encrypted whitelist feature value to the terminal device.
  • the feature value of the white list records the key information or fingerprint information of the white list, which can replace the white list in some scenarios, and the feature value of the white list occupies less space on the device, which can reduce the cost of mobile phones and other devices. storage overhead.
  • the remote device can further ensure the security of using the whitelist characteristic value by signing and/or encrypting the whitelist characteristic value.
  • whitelist feature values can be obtained from the whitelist through some algorithms or functions to obtain whitelist feature values.
  • Hash The function processes the key information in the whitelist, generates a Hash function value, and uses the Hash function value as the characteristic value of the whitelist.
  • the whitelist ID may be used as the whitelist characteristic value.
  • a characteristic value mechanism of the white list is proposed, and the remote device can obtain the characteristic value of the white list from the white list. Since the key information or fingerprint information of the whitelist is recorded in the characteristic value of the whitelist, it can replace the whitelist in some scenarios, and the characteristic value of the whitelist occupies less space on the device, which can reduce the storage capacity of mobile phones and other devices. overhead. In addition, the remote device can further ensure the security of using the whitelist characteristic value by signing and/or encrypting the whitelist characteristic value.
  • a method for remote control includes: obtaining an authorization token by a terminal device; sending first request information to a device management system, where the first request information includes an operation request and the authorization token; The operation request is used to request the device management system to issue a remote control command to the remote device, and the authorization token is used to verify the validity of the remote control command.
  • the authorization token content includes: at least one of token ID, issuer ID, authorized object ID, authorized content list, issuance time, validity period start time, and validity period end time; the authorized content list includes: controlled At least one of object identification, operation, and key parameters; the authorization token signature information includes signature data, or the authorization token signature information includes signature data and a signature algorithm.
  • the authorization token and the user's operation request can be carried in the first request information, and the device management system will issue remote control instructions to the remote device according to the user's operation request, and the authorization token is used to execute the remote control instruction
  • the legitimacy verification verify whether the remote control command is within the scope of the authorization token, to ensure that the remote control command is authorized by the user, and reduce the risk of user privacy disclosure and property loss.
  • the first request information further includes: a whitelist
  • the whitelist includes: whitelist content and whitelist signature information
  • the whitelist content includes: At least one of whitelist ID, issuer ID, authorized object ID, controlled object, authorized token ID list, and issuance time
  • the whitelist signature information includes signature data or, the whitelist signature information includes signature data and signature algorithm.
  • the content of the whitelist can be flexibly adjusted according to actual needs to adapt to different whitelist application scenarios.
  • the whitelist can include part of all the contents of the whitelist. Ensure safe use of the whitelist.
  • the method further includes: the terminal device acquires a whitelist, and verifies the validity of the whitelist; the verifying the validity of the whitelist includes the following content At least one of: Verify whether the whitelist issuer is valid, verify whether the whitelist authorized object is valid, verify whether the whitelist control object is valid, and verify whether the whitelist signature is consistent.
  • the terminal device can obtain the white list and verify the validity of the white list, and use the white list only when the validity verification of the white list passes, which ensures the security of using the white list.
  • the method further includes: the terminal device saves the characteristic value of the whitelist; the verifying the validity of the whitelist includes: the terminal device uses the whitelist Feature value, verifying the validity of the whitelist.
  • the terminal device may pre-store the feature value of the white list, and use the pre-stored feature value of the white list to verify the validity of the white list, and use the white list only when the validity verification of the white list passes.
  • the list ensures the security of using the white list.
  • the method further includes: the terminal device acquires the whitelist characteristic value from the remote device; the terminal device verifies the whitelist characteristic value, if Through the verification, the terminal saves the whitelist feature value.
  • the pre-saved whitelist feature values can be used to verify the feature values obtained from the remote device. If the feature values are consistent, the verification is passed, and the terminal device saves the whitelist feature values that pass the verification. In this way, the acquired whitelist feature values can be prevented from being illegally replaced.
  • the whitelist characteristic value is a signed and/or encrypted whitelist characteristic value.
  • the verifying the whitelist characteristic value by the terminal device further includes: performing signature verification and/or decryption on the whitelist characteristic value.
  • the terminal device after receiving the signed and/or encrypted whitelist feature value, the terminal device can verify the signature of the whitelist feature value, and/or decrypt the encryption of the whitelist feature value. Improve the security of using whitelist feature values.
  • the method further includes: the terminal device generates authorization token content according to the user's operation, and issues the authorization token; the terminal device determines the user's operation task type; the terminal device determines whether to issue a new authorization token and whether to update the whitelist according to the type of task operated by the user.
  • authorization tokens can be issued on demand according to user operations. Moreover, it can be decided whether to issue a new token and whether to update the whitelist according to the type of task operated by the user.
  • the authorization token can be applied to long-term authorization scenarios to ensure the safe use of the authorization token.
  • the method further includes: updating the key; the terminal device re-issues the whitelist and the authorization token with the updated key; and sends a third request to the device management system Information, the third request information includes the re-issued whitelist and authorization token.
  • this step may further include verifying the validity of the whitelist and the authorization token with the key before the update.
  • the authorized token and the whitelist are reissued by using the updated key to ensure safe use of the authorized token and the whitelist.
  • a method for remote control includes: receiving first request information, the first request information includes an operation request and an authorization token; generating a remote control instruction according to the operation request, and the remote control The instruction is used to instruct the remote device to execute the operation request.
  • the method further includes: sending second request information to the remote device, where the second request information includes a remote control instruction and an authorization token, and the authorization token It is used to verify the legality of the remote control instruction.
  • the device management system processes the received user's different operation requests, generates corresponding remote control instructions, and sends the operation instructions and authorization token to the remote device, so that the remote device can use the authorization token to remotely The legitimacy of the control command is verified to realize the remote control of the user.
  • a remote control method includes: a remote device receives second request information from a device management system, and the second request information includes a white list. The remote device verifies the validity of the whitelist.
  • the verification of the validity of the whitelist includes at least one of the following: verifying the consistency between the remote device identifier and the controlled object identifier in the whitelist, verifying the whitelist Whether the list issuance time is less than or equal to the first threshold, and verify the consistency of the whitelist signature.
  • the method further includes that the remote device determines a whitelist characteristic value according to the whitelist, and the whitelist characteristic value is used to identify the whitelist;
  • the remote device signs and/or encrypts the whitelist characteristic value;
  • the remote device sends the signed and/or encrypted whitelist characteristic value to the terminal device.
  • a remote control method includes: a terminal device acquires a whitelist, and verifies the validity of the whitelist; the verification of the validity of the whitelist includes: verifying whether the whitelist issuer is At least one of valid, verifying whether the authorized object of the whitelist is valid, verifying whether the control object of the whitelist is valid, and verifying whether the signature of the whitelist is consistent.
  • the method includes: the terminal device saves the whitelist characteristic value; the verifying the validity of the whitelist includes: the terminal device uses the whitelist characteristic value value to verify the validity of the whitelist.
  • the method includes: the terminal device obtains the whitelist feature value from the remote device; the terminal device verifies the whitelist feature value, and if the whitelist feature value passes the For the above verification, the terminal saves the whitelist feature value.
  • the whitelist characteristic value is a signed and/or encrypted whitelist characteristic value.
  • the verifying the whitelist characteristic value by the terminal device further includes: performing signature verification and/or decryption on the whitelist characteristic value.
  • the terminal device after receiving the signed and/or encrypted whitelist feature value, the terminal device can verify the signature of the whitelist feature value, and/or decrypt the encryption of the whitelist feature value. Improve the security of using whitelist feature values.
  • the method further includes: the terminal device generates authorization token content according to the user's operation, and issues the authorization token; the terminal device determines the user's operation Task type: the terminal device determines whether to issue a new authorization token and whether to update the white list according to the task type operated by the user.
  • the method further includes: the terminal device sends first request information to the device management system, where the first request information includes: a task request, an authorization token, and a white key list.
  • the whitelist includes: whitelist content and whitelist signature information;
  • the whitelist content includes: whitelist ID, issuer ID, authorized object ID At least one of , controlled object, authorization token ID list, and issuance time;
  • the whitelist signature information includes signature data or, the whitelist signature information includes signature data and a signature algorithm.
  • the method further includes updating a key; the terminal device uses the updated key to re-issue the whitelist and the authorization token; the terminal device Sending third request information to the device management system, where the third request information includes the re-issued whitelist and authorization token.
  • a remote control device which includes a transceiver unit and a processing unit; the transceiver unit is configured to: receive second request information, and the second request information includes a remote control instruction and an authorization token;
  • the processing unit is configured to: verify the validity of the authorization token, and if the authorization token is valid, use the authorization token to verify the legitimacy of the remote control instruction.
  • the processing unit is specifically configured to verify at least one of the following: verify whether the device management system is consistent with the authorized object ID, verify whether the ID of the controlled object is consistent with the remote device Whether the identification is consistent, verify the time validity of the token, verify whether the signature verification key of the token issuer has been configured on the remote device, and verify whether the digital signature of the authorization token is consistent.
  • the processing unit is specifically configured to verify at least one of the following: verifying whether the remote device identifier is consistent with the controlled object identifier in the authorization token, verifying whether the remote control At least one of whether the instruction is within the allowed operation range of the authorization token, and whether the verification key parameter is within the key parameter range of the authorization token.
  • the second request information includes a blacklist
  • the processing unit is specifically configured to: verify whether the authorization token ID is in the blacklist ID list.
  • the second request information includes a whitelist
  • the processing unit is specifically configured to: verify whether the authorization token ID is in the whitelist ID list.
  • the processing unit is further configured to verify the validity of the whitelist.
  • the processing unit is specifically configured to verify at least one of the following: verifying the consistency between the whitelist controlled object and the remote device identifier, verifying whether the whitelist issuance time is Less than or equal to the first threshold, verify the consistency of the whitelist signature.
  • the processing unit is further configured to: determine a whitelist characteristic value according to the whitelist, where the whitelist characteristic value is used to identify the whitelist;
  • the processing unit is further configured to sign and/or encrypt the whitelist characteristic value;
  • the receiving unit is further configured to: send the signed and/or encrypted whitelist characteristic value.
  • a remote control device which includes: an acquisition unit and a transceiver unit; the acquisition unit: used to acquire an authorization token, and the transceiver unit: used to send the first request information to the equipment management system, so
  • the first request information includes an operation request and an authorization token.
  • the operation request is used to request the device management system to issue a remote control command to the remote device, and the authorization token is used to verify the validity of the remote control command.
  • the authorization token includes authorization token content and authorization token signature information;
  • the authorization token content includes: token ID, issuer ID, authorized At least one of the authorization object ID, authorized content list, issuance time, validity period start time, and validity period end time.
  • the authorization content list includes: at least one of the controlled object identifier, operation, and key parameters;
  • the authorization token signature information includes signature data, or the authorization token signature information includes signature data and a signature algorithm.
  • the first request information further includes: a whitelist, and the whitelist includes: whitelist content and whitelist signature information; the whitelist content includes: At least one of whitelist ID, issuer ID, authorized object ID, controlled object, authorized token ID list, and issuance time; the whitelist signature information includes: signature data or, the whitelist signature information includes Signature data and signature algorithm.
  • the acquiring unit is further configured to: acquire a whitelist; the device further includes a processing unit configured to verify the validity of the whitelist; the processing unit specifically uses To verify at least one of the following: verifying whether the whitelist issuer is valid, verifying whether the whitelist authorized object is valid, verifying whether the whitelist control object is valid, and verifying whether the whitelist signature is consistent.
  • the device further includes a storage unit configured to save a whitelist characteristic value, and the whitelist characteristic value is used to identify the whitelist; the processing unit further uses a specific In: using the characteristic value of the whitelist to verify the validity of the whitelist.
  • the transceiver unit is further configured to acquire whitelist characteristic values from the remote device; the processing unit is further configured to verify the whitelist characteristic values, and if the verification passes , the storage unit saves the whitelist feature value.
  • the whitelist characteristic value is a signed and/or encrypted whitelist characteristic value.
  • the processing unit is further configured to perform signature verification and/or decryption on the whitelist feature value.
  • the processing unit in the device is further configured to: generate authorization token content, and issue the authorization token; determine the type of task operated by the user; according to the The type of task operated by the user determines whether to issue a new authorization token and update the whitelist.
  • the processing unit in the device is also used to update the key; re-issue the whitelist and authorization token with the updated key; the transceiver unit is also used to send The device management system sends third request information, where the third request information includes the re-issued whitelist and authorization token.
  • a remote-controlled authorization token device which includes a transceiver unit and a processing unit; the transceiver unit is configured to: receive first request information, and the first request information includes an operation request and a warrant The card; the processing unit is configured to: generate a remote control instruction according to the operation request, and the remote control instruction is used to instruct the remote device to execute the operation request.
  • the transceiving unit is further configured to: send second request information to the remote device, where the second request information includes the remote control instruction and the authorization token,
  • the authorization token is used to verify the validity of the remote control instruction.
  • a remote-controlled authorization token device which includes: at least one processor and a memory, the at least one processor is coupled to the memory, and is used to read and execute instructions in the memory , the device is used to execute the methods in the above aspects.
  • a computer-readable medium stores program codes, and when the computer program codes are run on a computer, the computer is made to execute the methods in the above aspects.
  • a chip in an eleventh aspect, includes: at least one processor and a memory, the at least one processor is coupled to the memory, and is used to read and execute instructions in the memory, and the device is used for The methods in each of the above aspects are performed.
  • a vehicle in a twelfth aspect, includes: at least one processor and a memory, the at least one processor is coupled to the memory, and is used to read and execute instructions in the memory, the vehicle in the The processor is configured to execute the methods in the above aspects.
  • FIG. 1 is a remote control system 100 provided by an embodiment of the present application.
  • Fig. 2 is a schematic diagram of a remote device provided by an embodiment of the present application.
  • Fig. 3 is a remote control solution provided by the embodiment of the present application.
  • Fig. 4 is another remote control solution provided by the embodiment of the present application.
  • Fig. 5 is a remote control method 500 provided by an embodiment of the present application.
  • FIG. 6 is a flowchart 600 of authorization token issuance and authentication provided by the embodiment of the present application.
  • Fig. 7 is an authorization token structure 700 provided by the embodiment of this application.
  • FIG. 8 is a flow chart 800 of authorization token validity verification provided by an embodiment of the present application.
  • FIG. 9 is a flow chart 900 of verifying the validity of a remote control instruction provided by an embodiment of the present application.
  • Fig. 10 is another remote control system 1000 provided by the embodiment of the present application.
  • Fig. 11 is a long-term task authorization token whitelist structure 1100 provided by the embodiment of the present application.
  • Fig. 12 is a flow chart 1200 of issuing a long-term mission authorization token white list provided by the embodiment of the present application.
  • FIG. 13 is a flow chart 1300 of validating a whitelist of a terminal device provided by an embodiment of the present application.
  • FIG. 14 is a flow chart 1400 of verifying the validity of a whitelist update of a remote device provided by an embodiment of the present application.
  • FIG. 15 is a flowchart 1500 of reissuing an authorization token provided by the embodiment of this application.
  • FIG. 16 is a flow chart 1600 of validity verification of a long-term authorization token provided by an embodiment of the present application.
  • Fig. 17 is a remote control device 1700 provided by an embodiment of the present application.
  • Fig. 18 is another remote control device 1800 provided by the embodiment of the present application.
  • APP an application program (Application, APP) refers to an application program on a terminal device such as a smart phone.
  • GNSS Global Navigation Satellite System
  • MAC Message authentication code (message authentication code, MAC) refers to a small piece of information generated after a specific algorithm to check the integrity of a certain piece of information and perform identity verification. It can be used to check whether the content of the message has been changed during delivery, whether the reason for the change is accidental or deliberate attack. At the same time, it can be used as the authentication of the message source to confirm the source of the message.
  • DTLS Datagram transport layer security
  • TLS transport layer security
  • UDP User Datagram Protocol
  • IOT The Internet of Things
  • the Internet of Things is a system that calculates the relationship between equipment, machinery, and digital machines. Human-device interaction.
  • the Internet of Things digitizes the real world and has a wide range of applications
  • Long-term task authorization token the authorization token whose validity period is longer than a certain threshold is defined as a long-term task authorization token.
  • Long-term mission authorization token whitelist a collection of valid long-term mission authorization token IDs, protected by the issuer's signature. Validation verification of long-term task authorization tokens is based on the verification of the validity of ordinary authorization tokens, and it is also necessary to ensure that the authorization token ID is in the white list.
  • Remote device the device that the user needs to remotely control, which can be a smart vehicle, smart home, etc.
  • Authorization token content refers to the information carried on the authorization token.
  • Hash function It converts an input of any length into a fixed-length output through a hash algorithm, and the output is a hash value. In other words, it is a function that compresses a message of any length into a message digest of a certain fixed length.
  • Fig. 1 is a remote control system provided by an embodiment of the present application.
  • the user 101 may be the owner or authorized person of the remote device 105, and is allowed to control the remote device 105 through the terminal remote control APP 102.
  • the terminal remote control APP 102 can be installed on terminal devices such as mobile phones, and the user 101 can remotely view, operate, and manage the remote device 105 through the APP 102.
  • the device management system 103 can be deployed on the cloud or on the server, and can support the access of the terminal remote control APP 102 and the remote device 105, and provide services for them.
  • the equipment management system 103 is operated and maintained by the operator or the equipment manufacturer's operation and maintenance personnel. After the remote device 105 is connected to the device management system 103 , the device management system 103 can centrally manage the remote device 105 . In the actual working process, the user 101 can directly or indirectly issue commands to the remote device 105 through the device management system 103 to control the remote device 105 to work.
  • the key management system 104 is responsible for distributing keys to the terminal remote control APP 102 and the remote device 105.
  • the key management system 104 may be an independent system, or integrated into the device management system 103 .
  • the key management system 104 can be deployed on the cloud or on a dedicated server, which is not limited in this embodiment of the present application.
  • the device owner or authorized personnel of the remote device 105 can control the remote device 105 locally, or remotely operate the remote device 105 through the terminal remote control APP 102.
  • the remote device 105 may be directly managed by the device owner or authorized personnel.
  • the remote device 105 can be a smart device such as a smart car or a smart home.
  • the remote control instruction issued by the device management system 103 can be an instruction to open/close the car door, and the remote device 105 receives the opening/closing command. After the command of closing/closing the car door, the command can be executed to realize the remote control of the opening/closing state of the car door by the user.
  • the instruction issued by the device management system 103 can also be an instruction to open/close the window, and the remote device 105 receives the instruction to close/open the window, and can execute the instruction to realize the remote control of the window opening/closing status of the vehicle by the user. control.
  • the instruction issued by the device management system 103 may also be an instruction to turn on/off the vehicle light, and the remote device 105 receives the instruction to turn on/turn on the vehicle light, and can execute the instruction to realize the remote control of turning on/off the vehicle light.
  • the remote control instruction issued by the device management system 103 may be an instruction to open/close the curtains. After the remote device 105 executes the instruction, the user can remotely control the opening/closing status of the curtains in the home.
  • the remote control instruction issued by the device management system 103 can also be to turn on/off the audio. After the remote device 105 executes the instruction, the user can remotely control the on/off status of the home audio, and then control the playback of music.
  • the time synchronization system 106 can provide time synchronization for the terminal 102 , the device management system 103 and the remote device 105 to ensure that the remote control system 100 operates well.
  • the time synchronization may be performed by GNSS or by other methods, which is not limited in this embodiment of the present application.
  • the communication link 107 may be a communication link between the terminal remote control APP 102 and the device management system 103. Through this link, the terminal remote control APP 102 enters the device management system 103 to remotely control the remote device 105.
  • the device management system 103 can authenticate and authorize the terminal remote control APP 102, so that a secure transmission channel, such as HTTPS, can be established between the two to ensure communication security.
  • the communication link 108 may be the communication link through which the remote device 105 accesses the device management system 103 .
  • the device management system 103 can manage and control the remote device 105 through this line. Authentication and authentication are performed between the remote device 105 and the device management system, and a secure transmission channel, such as DTLS, is established to ensure communication security.
  • the user signature key 109 may be distributed by the key management system 104, and the signature of the authorization token may adopt a message authentication code MAC of a symmetric key or a digital signature algorithm of an asymmetric key, and the like.
  • the signature of the authorization token adopts the message authentication code MAC based on the symmetric key
  • the user signature key 109 is the same as the remote device signature verification key 110; when the signature of the authorization token adopts the digital signature algorithm based on the asymmetric key, the user The signature key 109 is the private key of the user 101 .
  • the remote device signature verification key 110 may be distributed by the key management system 104, and the signature of the authorization token may use a message authentication code MAC of a symmetric key or a digital signature algorithm of an asymmetric key, and the like.
  • the signature of the authorization token adopts the message authentication code MAC based on the symmetric key
  • the user signature key 109 is the same as the remote device signature verification key 110; when the signature of the authorization token adopts the digital signature algorithm based on the asymmetric key, the user The signature key 109 is the public key of the user 101 .
  • Fig. 2 is a schematic diagram of an example of a remote device provided by an embodiment of the present application.
  • Vehicle 200 as shown in FIG. 2 may be an example of remote device 105 of FIG. 1 .
  • Vehicle 200 may include various subsystems, such as computing platform 210 , etc., and each subsystem may include multiple components.
  • Computing platform 210 may include at least one processor 211 that may execute instructions 213 stored in a non-transitory computer-readable medium such as memory 212 .
  • computing platform 210 may also be a plurality of computing devices that control individual components or subsystems of vehicle 200 in a distributed manner.
  • memory 212 may contain instructions 213 (eg, program logic) executable by processor 211 to perform various functions of vehicle 200 .
  • Instruction 213 eg, program logic
  • Memory 212 may also contain additional instructions, including instructions to send data to, receive data from, interact with, and/or control one or more of the other subsystems.
  • memory 212 may also store data such as road maps, route information, the vehicle's position, direction, speed, and other such vehicle data, among other information. Such information may be used by vehicle 200 and computing platform 210 during operation of vehicle 200 in autonomous, semi-autonomous, and/or manual modes.
  • the computing platform 210 may control functions of the vehicle 200 based on input received from various subsystems. In some embodiments, computing platform 210 is operable to provide control over many aspects of vehicle 200 and its subsystems.
  • one or more of these components described above may be installed separately from or associated with the vehicle 200 .
  • memory 212 may exist partially or completely separate from vehicle 200 .
  • the components described above may be communicatively coupled together in a wired and/or wireless manner.
  • FIG. 2 should not be construed as a limitation to the embodiment of the present application.
  • An autonomous vehicle traveling on a road may identify objects within its surroundings to determine adjustments to its current speed.
  • the objects may be other vehicles, traffic control devices, or other types of objects.
  • each identified object may be considered independently and based on the object's respective characteristics, such as its current speed, acceleration, distance to the vehicle, etc., may be used to determine the speed at which the autonomous vehicle is to be adjusted.
  • the vehicle 200 or a sensing and computing device (e.g., computing system 211, computing platform 210) associated with the vehicle 200 may be based on the identified characteristics of the object and the state of the surrounding environment (e.g., traffic, rain, traffic on the road). ice, etc.) to predict the behavior of the identified objects.
  • each identified object is dependent on the behavior of the other, so all identified objects can also be considered together to predict the behavior of a single identified object.
  • the vehicle 200 is able to adjust its speed based on the predicted behavior of the identified object.
  • the autonomous vehicle is able to determine what steady state the vehicle will need to adjust to (eg, accelerate, decelerate, or stop) based on the predicted behavior of the object.
  • other factors may also be considered to determine the speed of the vehicle 200 , such as the lateral position of the vehicle 200 on the traveling road, the curvature of the road, the proximity of static and dynamic objects, and the like.
  • the computing device may provide instructions to modify the steering angle of the vehicle 200 such that the self-driving vehicle follows a given trajectory and/or maintains contact with objects in the vicinity of the self-driving vehicle (e.g., , the safe lateral and longitudinal distances of cars in adjacent lanes on the road.
  • objects in the vicinity of the self-driving vehicle e.g., , the safe lateral and longitudinal distances of cars in adjacent lanes on the road.
  • the above-mentioned vehicle 200 may be a car, truck, motorcycle, public vehicle, boat, airplane, helicopter, lawn mower, recreational vehicle, playground vehicle, construction equipment, tram, golf cart, train, etc., the embodiment of the present application There is no particular limitation.
  • the user can directly or indirectly send commands to the remote device through the device management system to control the work of the remote device.
  • FIG. 3 is a remote control solution, and the remote control solution in FIG. 3 can be applied to the remote control system 100 in FIG. 1 .
  • the remote control solution can be divided into two stages, that is, the interaction between the user terminal and the device management system, and the interaction between the device management system and the remote device.
  • this remote control solution authentication, authentication and communication link security protection are completed between the user terminal and the equipment management system.
  • authentication, authentication and communication link security protection are completed between the equipment management system and the remote equipment. In this way, users can issue commands to remote devices through the device management system, thereby realizing remote control of devices.
  • the equipment management system is safe and reliable, that is, the equipment management system itself is safe, and the operation and maintenance personnel are also trustworthy. Since the remote device cannot verify the security of the device management system, it cannot confirm whether the received remote control command is authorized by the user. Once the device management system is attacked or the operation and maintenance personnel do not comply with the regulations, the remote device may be attacked, causing the user's privacy, property and life safety to be violated.
  • a device management system may be attacked by hackers.
  • hackers invade the device management system to steal and tamper with the user's remote control instructions. Since the remote device cannot identify whether the remote control command is authorized by the user, once the remote device executes the remote control command tampered with by the hacker, the user's property will suffer losses.
  • the operation and maintenance personnel of the equipment management system may cause remote control instructions not in line with the user's operation intention due to operations beyond the scope of their duties. Remote control instructions that do not conform to the user's operation intention will make the user's privacy and property safety not guaranteed.
  • FIG. 4 is another remote control solution, and the remote control solution in FIG. 4 can be applied to the remote control system 100 in FIG. 1 .
  • the user terminal and the remote device directly perform authentication, authentication and communication link encryption.
  • the device management system is only used as a communication link channel and does not participate in business processing.
  • the remote control scheme can improve the flexibility of the remote control scheme because the equipment management system does not need to intervene in authentication and other processing processes.
  • the equipment management system cannot actively trigger operation and maintenance, when the user controls the remote equipment, the scheme cannot control commands and parameters. Intelligent optimization cannot support automated management capabilities.
  • An embodiment of the present application provides a remote control method, in which a terminal device can issue an authorization token protected by a signature according to user operation content. Signature verification is performed on the authorization token on the remote device side to verify whether the remote control command is within the scope of the authorization token, so as to ensure that the remote control command is authorized by the user. In this way, it can be ensured that the remote control commands issued by the device management system are consistent with the intentions of the device owner or authorized manager; the damage to the remote device caused by the device management system being attacked or the operation and maintenance personnel operating in violation of regulations can be reduced. security threat.
  • FIG. 5 is an application and remote control authorization token method 500 provided by an embodiment of the present application, and the method can be applied to the remote control system 100 in FIG. 1 .
  • the method 500 may include the following steps.
  • the authorization token can be obtained from a device management system (for example, the device management system 103 in FIG. The validity of the token is verified.
  • the authorization token may be generated by a terminal device (for example, the terminal remote control APP 102 in FIG. 1).
  • generating the authorization token may include two steps: generating token content (TOKEN_CONTENT) and generating token signature (TOKEN_SIGNATURE) information.
  • generating token signature information includes two steps of generating signature data (SIGNATURE) and generating token signature (TOKEN_SIGNATURE).
  • the signature data may refer to data necessary to generate a token signature, and the signature data may be combined with a signature algorithm to obtain token signature information.
  • the MAC algorithm may be a secure message authentication code MAC such as HMAC or CMAC, which is not limited in this embodiment of the present application.
  • Method 2 Digital signature algorithm based on asymmetric key
  • SIGNATURE_DATA Signature(TOKEN_CONTENT,MAC_KEY)
  • the adopted digital signature algorithm may be an industry-wide algorithm such as RSA, DSA, ECDSA, etc., which is not limited in this embodiment of the present application.
  • the content of the authorization token may include: at least one item of token ID, issuer ID, authorized object ID, authorized content list, issuance time, validity period start time, and validity period end time.
  • the authorization list may include: at least one of the controlled object identifier, operation, and key parameters.
  • the issuer ID refers to the user ID
  • the remote device can load the token signature key according to the ID
  • the authorized object ID refers to the device management system ID
  • the controlled object ID refers to the remote device ID
  • the operation refers to the remote An operation controlled or a class of operations with the same security level
  • key parameters refer to the parameters of remote control that involve core interests such as user life and property safety
  • issuance time refers to the issuance time of the authorization token
  • the end time of the validity period refers to the end time of the validity period of the authorization token.
  • Authorization token signatures may include signature data or, data signatures may include signature data and a signature algorithm.
  • the signature algorithm refers to the algorithm used to encrypt the authorization token;
  • the signature data refers to the data result obtained after being encrypted by the signature algorithm.
  • the content and signature of the authorization token can be changed according to actual needs, for example, the authorization token can be composed of part of all the contents of the authorization token.
  • the authorization token signature may only contain signature data.
  • the authorization token can be attached with additional encryption measures such as secondary token signature and so on.
  • the signature algorithm carried by the authorization token is based on the consideration that the system can support multiple signature algorithms. If the system cannot directly obtain the algorithm carried by the token, the system will take time to check, which will result in wasted resources.
  • the card signature carries signature algorithm information. When using a pre-negotiated signature algorithm, or a signature algorithm adopted through information acquisition, the authorization token may not carry the signature algorithm.
  • the generated authorization token can flexibly adjust the content of the authorization token according to actual needs to adapt to different application scenarios of the authorization token.
  • the generated authorization token can be signed and/or encrypted. Secure the use of authorization tokens.
  • step S501 may also include obtaining a whitelist and verifying the validity of the whitelist.
  • the characteristic task of the long-term task may be canceled.
  • the authorization token also needs to be revoked synchronously, which requires a mechanism to ensure that the revoked authorization token is not illegally used.
  • the deployment of the whitelist is combined with the verification of the validity of the authorization token.
  • the whitelist scheme can also be replaced by a blacklist scheme, and the tokens that have been revoked are listed in the blacklist to ensure authorization. Tokens are safe to use.
  • the whitelist can be composed of whitelist content and whitelist signature information
  • the whitelist content can include: whitelist ID, issuer ID, authorized object ID, controlled object, authorization token ID list, issuance time At least one item
  • the whitelist signature information may include: signature data or, the whitelist signature information may include signature data and a signature algorithm.
  • the whitelist ID refers to the unique identification of the whitelist issued by the user; the issuance of this identification refers to the whitelist issuer ID; the authorization token ID list refers to the effective authorization token list issued by the user; the issuance time refers to the whitelist The time the list was issued.
  • the signature algorithm refers to the algorithm used to encrypt the whitelist; the signature data refers to the data result obtained after being encrypted by the signature algorithm.
  • the content of the whitelist can be flexibly adjusted according to actual needs to adapt to different application scenarios of the whitelist.
  • the whitelist can include part of all the contents of the whitelist, and for example, the signature data of the whitelist can be Encryption is used to ensure safe use of the whitelist.
  • verifying the validity of the whitelist may include verifying at least one of the following: verifying whether the whitelist issuer is valid, verifying whether the whitelist authorized object is valid, verifying whether the whitelist control object is valid, Verify that the whitelist signatures are consistent.
  • the terminal device can obtain the white list and verify the validity of the white list, and use the white list only when the validity verification of the white list passes, which ensures the safety of using the white list.
  • the whitelist scheme can also be replaced by a blacklist scheme, which can verify the validity of the blacklist, and use the blacklist on the basis of passing the blacklist verification.
  • step S501 may further include: the terminal device saves a whitelist characteristic value; the whitelist characteristic value is used to identify the whitelist, and verifying the validity of the whitelist includes: the terminal The device uses the characteristic value of the whitelist to verify the validity of the whitelist.
  • the feature value of the white list records the key information or fingerprint information of the white list, which can replace the white list in some scenarios, and the feature value of the white list occupies less space on the device, which can reduce the cost of mobile phones and other devices. storage overhead.
  • the remote device can further ensure the security of using the whitelist characteristic value by signing and/or encrypting the whitelist characteristic value.
  • step S501 may further include: the terminal device obtains the whitelist characteristic value from the remote device; the terminal device verifies the whitelist characteristic value, and if the verification is passed, the terminal saves the whitelist characteristic value.
  • Whitelist feature value the terminal device obtains the whitelist characteristic value from the remote device.
  • the characteristic value of the whitelist can be obtained from the whitelist through some algorithms or functions to obtain the characteristic value of the whitelist. Specifically, you can The key information in the whitelist is processed through the Hash function, the Hash function value is generated, and the Hash function value is used as the characteristic value of the whitelist.
  • the whitelist ID may be used as the whitelist characteristic value.
  • the terminal device may only save the characteristic values of the whitelist, which avoids the need for the terminal device to save the entire whitelist, and saves the storage cost of the terminal device.
  • the remote device feeds back the signed whitelist characteristic value.
  • the terminal calculates the feature value based on the previously obtained white list, and compares it with the feature value received from the remote device side. If they are consistent, it means that the white list has not been tampered with during the distribution process, and the white list is valid.
  • the terminal device obtains the white list from the device management system, and compares the characteristic value calculated from the obtained white list with the characteristic value stored locally on the terminal device.
  • the characteristic value of the whitelist can also be replaced by the characteristic value of the blacklist, and the validity of the blacklist is verified by using the characteristic value of the blacklist in the process of issuing or reissuing the blacklist.
  • the whitelist feature value in step S501 is a signed and/or encrypted whitelist feature value.
  • step S501 may further include: the terminal device generates authorization token content according to the user's operation, and issues the authorization token; the terminal device determines the task type operated by the user; , to determine whether to issue a new authorization token and update the whitelist.
  • Table 1 presents an illustrative example of determining whether to issue a new token and whether to update the whitelist according to the type of task operated by the user.
  • the remote device only needs to execute the user's change operation command according to the original white list and authorization token.
  • whether to issue a new token and whether to update the whitelist can be determined according to the type of task operated by the user.
  • the authorization token can be applied to long-term authorization scenarios and ensure the safe use of the authorization token. In addition, it can also decide whether to issue a new token and update the blacklist according to the type of task operated by the user. Adapt authorization tokens to different application scenarios.
  • step S501 may also include: updating the key; re-issuing the whitelist and the authorization token with the new key; sending a third request message to the device management system, the third request message includes the re-issued Whitelist and authorization tokens.
  • the authorization token is sent to the device management system.
  • this step may further include verifying the validity of the whitelist and the authorization token with the key before the update.
  • the authorized token and the whitelist are re-issued through the updated key to ensure safe use of the authorized token and the whitelist.
  • the key can also be used to re-issue the authorization token and blacklist, so that the authorization token can be adapted to different application scenarios.
  • the terminal device sends first request information to the device management system.
  • the first request information includes an operation request and an authorization token.
  • the operation request is used to instruct the device management system to send a remote control instruction to the remote device.
  • the authorization token includes the content of the authorization token and the signature information of the authorization token, and is used to verify the legitimacy of executing the remote control instruction.
  • the first request information further includes a white list.
  • the terminal device may verify the validity of the whitelist, and only carry the whitelist in the first request information if the verification of the validity of the whitelist passes The whitelist.
  • the white list in order to support the use of long-term task authorization tokens, when it comes to long-term task authorization token changes, it is necessary to deploy the white list in the first request information, and send the white list to the remote device to facilitate subsequent
  • the remote device verifies whether the content of the authorization token is in the white list, prevents the revoked white list from being illegally used, and ensures the security of the use of the token.
  • the white list can also be replaced with a black list to adapt authorization tokens to different application scenarios.
  • the device management system performs business processing.
  • the device management system processes the received user's different operation requests, generates corresponding remote control instructions, and sends the operation instructions to the remote device, thereby realizing the remote control of the user.
  • this step also includes storing the authorization token and the white list by the device management system.
  • the device management system can save the authorization token and the white list of long-term authorization tokens for subsequent business use.
  • the device management system sends the second request information to the remote device.
  • the second request information may include a remote control instruction and an authorization token
  • the remote control instruction is used to instruct the remote device to perform a corresponding operation
  • the authorization token is used to verify the legality of executing the remote control instruction
  • the second request information may further include a white list, and after the white list is sent to the remote device, the remote device may update the white list.
  • verifying the validity of the token may include at least one of the following: verifying whether the device management system is consistent with the authorized object ID, verifying whether the controlled object ID is consistent with the remote device ID, verifying the time validity of the token, verifying Whether the signature verification key of the token issuer has been configured on the remote device, and verify whether the digital signature of the authorization token is consistent.
  • verifying the legitimacy of the remote control instruction may include at least one of the following: verifying whether the remote device identifier is consistent with the controlled object identifier in the authorization token, verifying whether the remote control instruction is within the allowed operating range of the authorization token, Verify that the key parameter is within the key parameter range of the authorization token.
  • the received authorization token can be validated, and the authorization token can be used to verify the legitimacy of the remote control instruction after the validity verification is passed. Only when both verifications are passed, the remote device can Execute remote control commands. In this way, it can be ensured that the remote control instruction is consistent with the intention of the device owner/authorized person, reducing the risk of user privacy leakage and property loss.
  • the second request information may further include a whitelist
  • verifying the validity of the token further includes: verifying whether the authorization token ID is in the whitelist ID list.
  • the second request information may further include a blacklist
  • verifying the validity of the token further includes: verifying whether the authorization token ID is in the blacklist ID list.
  • the whitelist can be released while signing the authorization token, and then judge whether the authorization token ID is in the whitelist ID list after the authorization token is verified, so as to ensure that the authorization token is not revoked.
  • Authorization tokens can only be used if they pass the whitelist verification. It is also possible to publish the blacklist while signing the authorization token, and judge whether the authorization token ID is in the blacklist ID list on the basis of the authorization token verification. The authorization token ID can only be used if it is not in the blacklist list. . Through the above method, it can be guaranteed that the authorization token has not been revoked, reducing the risk of user's privacy leakage and property loss.
  • step S505 further includes: verifying the validity of the whitelist.
  • Verifying the validity of the whitelist may include at least one of the following: verifying the consistency of the remote device identifier and the controlled object identifier in the whitelist, verifying whether the whitelist issuance time is less than or equal to the first threshold, and verifying the consistency of the whitelist signature .
  • verifying whether the whitelist issuance time is less than or equal to the first threshold may refer to judging whether the whitelist issuance time is within the allowable range of the current time difference of the remote device system.
  • the first threshold represents the maximum value allowed by the current time difference of the remote device system, and its value can be preset according to the actual situation.
  • the allowable range of the current time difference of the remote device system is set to be within 10 seconds, and when the whitelist issuance time is 8 seconds, the whitelist issuance time meets the requirements. When the whitelist issuance time is 12 seconds, the whitelist issuance time does not meet the requirement, and the whitelist update fails.
  • Verifying the consistency of the whitelist signature can refer to using the key to verify the validity of the whitelist signature. If the whitelist signature is consistent with the key, the signature verification is successful; if the whitelist signature is inconsistent with the key, the signature verification fails. Whitelist update failed.
  • the validity verification of the released white list can be performed, by verifying the consistency between the remote device ID and the controlled object ID in the authorization token, verifying the white list and verifying whether the white list issuance time is less than or equal to the first threshold
  • the method of verifying the consistency of the whitelist signature ensures that the whitelist is not attacked, which can reduce the risk of user privacy leakage and property loss.
  • the scheme for verifying the validity of the whitelist can also be replaced by a scheme for verifying the validity of the blacklist.
  • step S505 it also includes: signing and/or encrypting the whitelist characteristic value; the remote device sends the signed and/or encrypted whitelist characteristic value to the terminal device for The terminal device confirms that the issued white list is consistent with the white list received by the remote device.
  • the remote device may calculate the whitelist characteristic value according to the whitelist, and sign or encrypt the characteristic value by means of a signature key or encryption.
  • the signature key may adopt either a symmetric key or a private key of a remote device.
  • the remote device can send the signed or encrypted whitelist characteristic value to the terminal device, and the terminal device verifies that the received characteristic value is consistent with the sent whitelist characteristic value, and saves the whitelist characteristic value if it passes the verification.
  • the whitelist feature value is used for subsequent verification of the validity of the whitelist obtained from the device management system.
  • a characteristic value mechanism of the white list is proposed, and the remote device can obtain the characteristic value of the white list from the white list. Because the key information or fingerprint information of the whitelist is recorded in the characteristic value of the whitelist, it can replace the whitelist, and the characteristic value of the whitelist occupies less space on the device, which can reduce the storage cost of mobile phones and other devices. In addition, the remote device can further ensure the security of using the whitelist characteristic value by signing and/or encrypting the whitelist characteristic value. In addition, the whitelist eigenvalue scheme can also be replaced by a blacklist eigenvalue scheme.
  • FIG. 6 is a flowchart 600 of authorization token issuance and authentication provided by the embodiment of the present application.
  • the method in FIG. 6 can be applied to the remote control system 100 in FIG. 1 .
  • the method may include the following steps.
  • the user monitors, views and operates the remote device through the terminal remote control APP.
  • the system automatically generates the authorization token content 710 (TOKEN_CONTENT) in the authorization token 700 according to the user's operation on the terminal remote control APP.
  • Authorization token content 710 may include: token ID 711 (TOKEN_ID), issuer ID 712 (ISSUER_ID), authorized object ID 713 (AUTHORIZED_OBJ_ID), authorized content list 714 (multiple groups possible), controlled ID 715 (OBJECT_ID) , operation 716 (OPERATE), key parameter 717 (KEY_PARAMETER), issue time 718 (ISSUE_TIME), validity period start time 719 (VALIDITY_START_TIME) and validity period end time 720 (VALIDITY_EXIRATION_TIME).
  • the remote device can load the signature key of the token according to the issuer ID 712
  • the authorized object ID 713 can be the ID of the device management system
  • the controlled ID 715 can be the remote device ID
  • the operation 716 can refer to an operation of remote control Or a type of operation with the same security level
  • the key parameter 717 may refer to the remote control parameters related to the core interests of the user's life and property safety.
  • the key parameter 717 may be a specific value or a value range of a parameter, which is not limited in this embodiment of the present application.
  • the equipment management system can adjust the parameter within the value range.
  • the validity period start time 719 can be expressed by the following formula:
  • Token validity start time current system time – time synchronization deviation (TIME_SYN_ERROR)
  • the validity period end time 720 can be expressed by the following formula:
  • Token validity start time current system time + operation reserved time (OPERATE_RESERVE_TIME) + time synchronization deviation (TIME_SYN_ERROR)
  • the operation reserved time (OPERATE_RESERVE_TIME) can be preset according to the complexity of the operation
  • the time synchronization deviation (TIME_SYS_ERROR) refers to the tolerable time synchronization deviation among multiple devices in the system.
  • the embodiment of the present application does not limit the specific values of the operation reservation time and the time synchronization deviation.
  • the system automatically generates an authorization token signature 730 (TOKEN_SIGNATURE) in the authorization token 700 according to the user's operation on the terminal remote control APP.
  • the generation method of the authorization token signature 730 can be expressed by the following formula:
  • generating the signature data 732 may adopt a message authentication code MAC algorithm based on a symmetric key or a digital signature algorithm based on an asymmetric key.
  • the authorization token may be composed of authorization token content 710 and authorization token signature 730 . It can be expressed by the following formula.
  • AUTHRIZATION_TOKEN TOKEN_CONTENT
  • the manner of generating the authorization token in the embodiment of the present application is only an exemplary description, and other manners may also be used for generating the authorization token.
  • the authorization token may only consist of part of the contents of the authorization token 710 , and for another example, the authorization token signature 730 may only contain the signature data 732 .
  • additional encryption measures such as secondary token signatures may be added to the authorization token, and this embodiment of the present application does not limit the way of generating the authorization token.
  • authorization tokens can be automatically generated according to user operations, and tokens can be issued on demand to ensure the minimization of the scope of authorization and reduce the risk of user privacy disclosure and property loss.
  • the generated authorization token can flexibly adjust the content of the authorization token according to actual needs to adapt to different application scenarios of the authorization token.
  • the generated authorization token can be signed and/or encrypted to ensure the use of the authorization token Safety.
  • the terminal remote control APP sends first request information to the device management system.
  • the first request information includes an operation request and an authorization token.
  • the device management system performs service processing.
  • the device management system processes the received user's different operation requests, generates corresponding remote control instructions, and sends the operation instructions to the remote device, thereby realizing the remote control of the user.
  • the device management system sends the second request information to the remote device.
  • the second request information includes a remote control instruction and an authorization token.
  • the communication protocol between the terminal remote control APP and the device management system, and the communication protocol between the device management system and the remote device can be decoupled by means of an authorization token.
  • the equipment management system has a relatively sufficient degree of freedom in the remote control algorithm, and can issue remote control optimal parameters within the scope of authorization to achieve a good remote control effect.
  • the remote device verifies the validity of the token.
  • the remote device executes the user's remote control instruction.
  • the user realizes the remote control of the remote device.
  • the remote device records the execution of the remote control instruction.
  • the owner or manager of the remote device can check the execution process and execution result of the remote control command through the log.
  • the owner or manager of the remote device can understand the reason for the task execution failure through the log record, or the remote device can also feed back information to the owner or manager of the device in other ways.
  • the owner or manager of the equipment can know the reasons for the task execution failure in time through the information fed back by the remote equipment, and then take certain improvement measures to ensure that the next remote control task can be successfully executed.
  • the remote control APP of the terminal issues an authorization token to transmit instruction information to the remote device, and the remote device can verify the token and the remote control command to ensure that the remote control command is consistent with the device owner/authorized
  • the intent of the user is the same, reducing the risk of user privacy leakage and property loss.
  • Fig. 8 is a flow chart 800 of authorization token validity verification provided by the embodiment of the present application.
  • the method 800 can be applied to the authorization token validity verification in Fig. 6.
  • the method 800 may include the following steps .
  • step S802 verify the consistency between the remote control command issued by the device management system and the authorized object ID (AUTHORIZED_OBJ_ID), and if they are consistent, go to step S802. If the verification fails, the remote control process ends.
  • AUTHORIZED_OBJ_ID the authorized object ID
  • step S802. Verify whether the ID of the controlled object is consistent with the remote device identifier. If they are consistent, proceed to step S803. If they are not consistent, the remote control process ends.
  • the validity of the verification token time can be determined by judging whether the current time of the system meets a preset range.
  • the time validity verification can be passed. Otherwise, the verification fails, and the remote control process ends.
  • the time validity verification is passed. Otherwise, the verification fails, and the remote control process ends.
  • the remote device signature verification key distributed in advance can be obtained through the issuer ID 721 and the signature algorithm 731. If the signature verification key has been configured, go to step S804. If the verification fails, the remote control process ends.
  • verification can be performed through the following steps.
  • Input authorization token, remote device signature verification key
  • FIG. 9 is a flow chart 900 for verifying the validity of a remote control instruction provided by an embodiment of the present application.
  • the method 900 can be applied to the verification of the validity of the remote control instruction shown in FIG. 6 .
  • the method 900 may include the following steps.
  • step S902 verify whether the device object ID in the remote control instruction is consistent with the controlled object identifier 713 in the authorization token, if they are consistent, go to step S902, if not, the remote control process ends.
  • step S903 verify whether the operation instruction in the remote control instruction is consistent with the operation 716 in the authorization token or whether it belongs to the scope of the operation 716 list. If they are consistent or within the range of the list, go to step S903; if they are inconsistent or not within the range of the list, the remote control procedure ends.
  • the remote control process ends.
  • the above-mentioned embodiment provides the implementation scheme of the authorization token in the real-time interaction scenario.
  • another common application scenario is periodic control, reservation control, and authorization management, such as scheduled car backup function, reserved car backup function, commissioned remote diagnosis and other functions.
  • the user is offline, and the device management system initiates the control of the remote device instead of the user.
  • the user cannot issue the authorization token immediately, and needs to issue the authorization token in advance and save it in the device management system.
  • the validity period of the authorization token will be relatively long.
  • Fig. 10 is another remote control system 1000 provided by the embodiment of the present application, the remote control system can support the remote control scheme of long-term authorization token.
  • the user 1001 may be the owner or authorized person of the remote device 1005, and is allowed to control the remote device 1005 through the terminal remote control APP 1002.
  • the terminal remote control APP 1002 can be installed on terminal devices such as mobile phones, and the user 1001 can remotely view, operate, and manage the remote device 1005 through the terminal remote control APP 1002.
  • the device management system 1003 can be deployed on the cloud or on the server, and can support the access of the terminal remote control APP 1002 and the remote device 1005, and provide services for them.
  • the key management system 1004 is responsible for distributing keys to the terminal remote control APP 1002 and the remote device 1005. It can be an independent system, or integrated into the device management system 1003 . It can be deployed on the cloud or on a dedicated server, which is not limited in this embodiment of the present application.
  • the remote device 1005 is owned by the device owner, which can be a smart car, smart home, etc.
  • the device owner or authorized personnel can operate the remote device 1005 at the near end, or remotely operate the remote device 1005 through the terminal remote control APP 1002 .
  • the remote device 1005 may be directly managed by the device owner or authorized personnel.
  • the time synchronization system 1006 can provide time synchronization for the terminal 1002, the device management system 1003 and the remote device 1005, so as to ensure that the remote control system 1000 works well.
  • the time synchronization may be performed by GNSS or by other methods, which is not limited in this embodiment of the present application.
  • the communication link 1007 may be a communication link between the terminal remote control APP 1002 and the device management system 1003. Through this link, the terminal remote control APP 1002 enters the device management system 1003 to remotely control the remote device 1005.
  • the device management system 1003 can authenticate and authorize the terminal remote control APP 1002, so that a secure transmission channel, such as HTTPS, can be established between the two to ensure communication security.
  • Communication link 1008 may be a communication link through which remote device 1005 accesses device management system 1003 .
  • the device management system 1003 can manage and control the remote device 1005 through this line. Authentication and authentication are performed between the remote device 1005 and the device management system, and a secure transmission channel, such as DTLS, is established to ensure communication security.
  • a secure transmission channel such as DTLS
  • the user signature key 1009 can be distributed by the key management system 1004, and the signature of the authorization token can adopt a message authentication code MAC of a symmetric key or a digital signature algorithm of an asymmetric key, and the like.
  • the signature of the authorization token adopts the message authentication code MAC based on the symmetric key
  • the user signature key 1009 is the same as the remote device signature verification key 1010; when the signature of the authorization token adopts the digital signature algorithm based on the asymmetric key, save The private key of the user 1001 is used for the signature of the authorization token and the white list signature of the long-term authorization token; at the same time, the public key of the remote device 1005 is saved for communication with the remote device.
  • the remote device signature verification key 1010 may be distributed by the key management system 1004, and the signature of the authorization token may adopt a message authentication code MAC of a symmetric key or a digital signature algorithm of an asymmetric key, and the like.
  • the user signature key 1009 is the same as the remote device signature verification key 1010;
  • the terminal The remote control APP 1002 saves the private key of the user 1001, which is used to issue authorization token signatures and long-term authorization token whitelist signatures; at the same time, it saves the public key of the remote device 1005, which is used to verify the characteristics of the long-term authorization token whitelist returned by the remote device The signature of the value.
  • the public key of the user 1001 is saved on the remote device side for signature verification of the authorization token and long-term authorization token whitelist; and the private key of the remote device 1005 is saved for the whitelist feature during the whitelist release process The value is signed.
  • the authorization token 1011 is stored in the device management system 1003 side after the terminal remote control APP 1002 issues an authorization token with a long validity period for use in subsequent remote control services.
  • the long-term task authorization token white list 1012 is a list of long-term authorization token IDs, which are protected by signatures of user keys.
  • the white list of long-term task authorization tokens is issued and stored in the device management system 1003 and the remote device 1005.
  • the long-term task authorization token whitelist feature value 1013 is an identifier for globally distinguishing the whitelist, and the unique information that can identify the whitelist can be obtained from the whitelist, which can be composed of fields in the whitelist, issuer ID, whitelist ID, Items such as issuance time and fingerprint information are combined into whitelist characteristic value 1013.
  • the whitelist feature value 1013 is generated by the whitelist, which can ensure that the whitelist saved by the device management system 1003, the whitelist sent to the remote device 1005, and the whitelist issued by the terminal are consistent, ensuring the security of the whitelist release and storage process.
  • Fig. 11 is a long-term task authorization token whitelist structure 1100 provided by the embodiment of the present application.
  • the long-term task authorization white list in FIG. 11 can be applied to the remote control system 1000 in FIG. 10 .
  • the long-term mandate whitelist may include whitelist content 1110 and whitelist signature 1120 .
  • the whitelist content 1110 may include: whitelist ID 1111, issuer ID 1112, authorized object ID 1113, controlled object 1114, authorization token ID list 1115, and issuance time 1116.
  • Whitelist signature 1120 may include signature algorithm 1221 and signature data 1122 .
  • the whitelist ID 1111 can refer to the unique identifier of the whitelist issued by the user
  • the issuer identification 1112 can refer to the whitelist issuer ID
  • the authorization token ID list 1115 can refer to the unrevoked authorization token issued by the user list
  • the issuance time 1116 may refer to the issuance time of the whitelist.
  • the signature algorithm 1221 may refer to a whitelist signature algorithm, such as HMAC, RSA and other algorithms.
  • Signature data 1222 may refer to the digital signature (or message authentication code) result of the whitelist content by the user's key.
  • the examples of the content and signature of the long-term authorization token whitelist are only exemplary illustrations, and the items in the content and signature of the long-term authorization token whitelist can be adjusted according to actual needs to suit Different whitelist application scenarios, for example, the whitelist may include part of all contents of the whitelist, and for example, the signature data of the whitelist may be encrypted to ensure the security of the use of the whitelist.
  • a scheme of signing a white list of authorization tokens for long-term tasks is adopted. Only the authorized tokens in the whitelist are valid, and it supports remote control solutions in scenarios such as periodic control, reservation control, and authorization management.
  • FIG. 12 is a flow chart 1200 of issuing a long-term mission authorization token whitelist provided by an embodiment of the present application.
  • the method 1200 can be applied to the remote control system 1000 in FIG. 10 .
  • Method 1200 may include the following steps.
  • the terminal remote control APP sends request information for obtaining a white list of long-term authorization tokens to the device management system.
  • the device management system returns the white list, and the terminal remote control APP obtains the white list of long-term authorization tokens.
  • the long-term authorization whitelist may be stored in the device management system, may also be stored in the terminal device, or may be stored in other locations, which is not limited in this embodiment of the present application.
  • the terminal remote control APP verifies the validity of the white list.
  • S1204 determine whether to issue a new authorization token and whether to update the white list.
  • the user change operation command needs to be executed according to the original whitelist and authorization token.
  • step S1205 if it is determined in step S1204 that a new authorization token needs to be issued, issue a new authorization token in this step, and if it is determined in step S1204 that a new authorization token does not need to be issued, skip this step.
  • step S1206 If it is determined in step S1204 that the whitelist needs to be updated, update the whitelist in this step, and if it is determined in step S1204 that the whitelist does not need to be updated, skip this step.
  • the terminal operation control APP sends first request information to the device management system.
  • the first request information includes: a task request, an authorization token, and a white list of long-term authorization tokens.
  • remote control schemes in scenarios such as periodic control, reservation control, and authorization management are supported by deploying a whitelist in the first request information.
  • the use security of the authorization token is guaranteed.
  • the device management system processes the received user's different operation requests, generates corresponding remote control instructions, and sends the operation instructions to the remote device, thereby realizing the remote control of the user.
  • the device management system saves the authorization token and the long-term authorization token white list.
  • the device management system can save the authorization token and the white list of long-term authorization tokens for subsequent business use.
  • the device management system sends the long-term authorization token white list to the remote device, so that the remote device updates the white list.
  • the remote device After receiving the long-term authorization token whitelist, the remote device verifies the validity of the whitelist, and updates the whitelist on the remote device side if the verification is passed; otherwise, the update of the whitelist fails.
  • the remote device signs the whitelist feature value.
  • the key information or fingerprint information of the whitelist is recorded in the characteristic value of the whitelist, which can replace the whitelist in some scenarios, and the characteristic value of the whitelist occupies less space on the device, which can reduce the storage cost of mobile phones and other devices .
  • the remote device can calculate the characteristic value from the obtained white list, and sign the characteristic value by using the signature key of the remote device.
  • different ways can be used to obtain the characteristic value of the whitelist. For example, some key information (key fields, bytes, etc.) can be extracted from the whitelist through some algorithms or functions to obtain the characteristic value of the whitelist. Specifically, you can The key information in the whitelist is processed through the Hash function, the Hash function value is generated, and the Hash function value is used as the characteristic value of the whitelist.
  • the whitelist ID may be used as the whitelist characteristic value.
  • the signature key used may be a symmetric key or a private key of the remote device.
  • the signature can also be replaced by the remote device encrypting the characteristic value of the white list. Both the encryption processing and the signature are to improve the security of using the characteristic value of the white list.
  • the remote device returns the whitelist feature value and its signature to the terminal remote control APP.
  • the remote device may send the signed whitelist characteristic value to the terminal device, so that the terminal device verifies and saves the whitelist characteristic value.
  • step S1212 the whitelist characteristic value is encrypted, then this step is that the remote device returns the encrypted whitelist characteristic value to the remote control APP of the terminal.
  • the terminal remote control APP uses the symmetric key or the public key of the remote device to perform secondary signature verification on the whitelist characteristic value.
  • the terminal remote control APP can use the symmetric key or the public key of the remote device to perform secondary signature authentication on the signed whitelist feature value. If the signature authentication is passed, the whitelist feature value and its new signature will be saved. If If the authentication fails, the whitelist feature value is discarded or revoked. In this way, the validity of the white list obtained from the outside can be guaranteed, and the white list can be prevented from being illegally replaced.
  • the secondary signature verification process of the whitelist feature value includes: 1) verify the signature of the whitelist feature value with a symmetric key or the public key of the remote device, and enter the next step if the verification is passed; The whitelist feature value is generated from the list; and compared with the feature value returned by S1213, if they are consistent, the whitelist is issued successfully; otherwise, the whitelist has been illegally tampered with, and the whitelist revocation process needs to be triggered.
  • this step is to perform secondary authentication on the encrypted whitelist.
  • the terminal remote control APP signs or encrypts the latest whitelist feature value, and stores the whitelist feature value and its signature locally.
  • the white list is released while the authorization token is signed, and the validity of the white list is verified to ensure that the white list is not attacked, which can reduce the risk of user privacy leakage and property loss.
  • the embodiment of the present application can ensure the effectiveness of obtaining the whitelist from outside through the locally saved whitelist feature value mechanism, prevent the white list from being illegally replaced, and reduce the storage cost of mobile phones and other devices through the feature value mechanism.
  • the whitelist scheme can also be replaced by a blacklist scheme, which can perform validity verification, feature value verification, etc. on the blacklist.
  • FIG. 13 is a flow chart 1300 of verifying the validity of a whitelist of a terminal device according to an embodiment of the present application.
  • the method 1300 can be applied to step S1203 of the process of verifying the validity of a whitelist by a terminal device in FIG. 12 .
  • the method 1300 may include the following steps.
  • step S1302 check that the issuer ID 1112 in the white list obtained from the device management system is consistent with the identity ID of the terminal remote control APP, if they are consistent, proceed to step S1302, if not, the white list is invalid, and the verification fails.
  • step S1303 check that the authorized object identifier 1113 in the whitelist obtained from the device management system is consistent with the currently logged-in device management system ID, if they are consistent, proceed to step S1303, if not, the whitelist is invalid, and the verification fails.
  • step S1304 check that the controlled object identifier 1113 in the whitelist obtained from the device management system is consistent with the remote device ID being operated, and if they are consistent, proceed to step S1304; if not, the whitelist is invalid and the verification fails.
  • the verification terminal device verifies the consistency between the saved characteristic value and the obtained characteristic value calculated by the white list. If it is verified that the characteristic values of the white list are consistent, proceed to step S1305. If the characteristic values of the verified white list are inconsistent, the white list is invalid and the verification fails. In order to ensure that the saved whitelist is not tampered with, the characteristic value of the whitelist can be protected by means of signature or encryption.
  • the validity verification is performed on the whitelist issued by the user himself. If the verification is passed, it is verified by whitelist validity. If the signature validity verification fails, the whitelist is invalid and the whitelist validity verification fails.
  • FIG. 14 is a flow chart 1400 of verifying the validity of a whitelist update of a remote device provided by an embodiment of the present application. This method can be applied in the process of verifying the validity of the whitelist in step S1211/S1212 in FIG. 12 , and the method 1400 may include the following steps.
  • step S1402 compare the controlled object in the whitelist with the remote device identifier, and if they are consistent, proceed to step S1402; if not, the whitelist update validity verification fails.
  • verifying whether the whitelist issuance time is less than or equal to the first threshold may refer to judging whether the whitelist issuance time is within a range allowed by the current time difference of the remote device system.
  • verifying the consistency of the whitelist signature can refer to using a key to verify the validity of the whitelist signature. If the whitelist signature is consistent with the key, the signature verification is successful and the whitelist update is successful; If the key is inconsistent, the signature verification fails and the whitelist update fails.
  • the terminal remote control APP may need to update the key to ensure the security of the user's authorization token. In this case, it is necessary to re-issue the issued long-term authorization token and long-term authorization token whitelist.
  • FIG. 15 is a flow chart 1500 of reissuing an authorization token provided by an embodiment of the present application.
  • the method 1500 can be applied to the remote control system 1000 in FIG. 10 .
  • Method 1500 may include the following steps.
  • the terminal remote control APP updates the key, and at the same time, the key management system needs to update the latest key on the terminal remote control APP and the remote device at the same time.
  • the terminal remote control APP acquires a long-term authorization token and a white list from the device management system.
  • the terminal remote control APP verifies the validity of the obtained whitelist with the key before the update, and the verification of the validity of the whitelist includes meeting the following two conditions:
  • the feature value of the white list is calculated based on the white list obtained from the device management system, and the feature value is consistent with the feature value saved by the terminal remote control APP.
  • the terminal remote control APP verifies the validity of the authorization token with the key before the update, and insists that the authorization token ID is in the authorization token ID list of the white list. If the validity verification is passed, go to step S1505; if the validity verification is not passed, the process is terminated, and the long-term task needs to be recreated.
  • the terminal remote control APP uses the updated key to re-issue the long-term authorization token white list.
  • the terminal remote control APP re-issues the long-term authorization token with the updated key.
  • the terminal remote control APP sends third request information to the device management system.
  • the third request information includes a long-term authorization token and a white list of long-term authorization tokens.
  • the device management system saves the authorization token and the long-term authorization token white list.
  • the device management system can save the authorization token and the white list of long-term authorization tokens for subsequent business use.
  • the device management sends the long-term authorization token whitelist to the remote device, so that the remote device updates the whitelist.
  • the remote device After receiving the long-term authorization token whitelist, the remote device updates the whitelist, and verifies the validity of the updated whitelist.
  • verifying the validity of the whitelist includes at least one of the following: verifying the consistency between the controlled object in the whitelist and the identity of the remote device, verifying whether the whitelist issuance time is less than or equal to the first threshold, verifying the signature of the whitelist consistency.
  • the remote device performs whitelist characteristic value signature.
  • the remote device can calculate the feature value from the obtained white list, and sign the feature value by using the signature key.
  • the signature key may adopt either a symmetric key or a private key of a remote device.
  • the remote device returns the whitelist characteristic value signature to the terminal remote control APP.
  • the remote device may send the signed whitelist characteristic value to the terminal device, so that the terminal device verifies and saves the whitelist characteristic value.
  • the terminal remote control APP performs a second signature verification on the white list.
  • the terminal remote control APP can perform secondary signature authentication on the signed whitelist feature value. If the signature authentication is passed, the whitelist feature value and its new signature will be saved. If the authentication fails, the whitelist feature value will be discarded. value. In this way, the validity of the whitelist obtained from the outside can be guaranteed, and the whitelist can be prevented from being illegally replaced
  • the secondary signature verification process of the whitelist characteristic value includes: 1) verify the whitelist characteristic value signature with a symmetric key or the public key of the remote device, and enter the next step if the verification is passed; The whitelist feature value is generated from the list; and compared with the feature value returned by S1512, if the consistent whitelist is successfully issued; otherwise, the whitelist has been illegally tampered with, and the whitelist revocation process needs to be triggered.
  • the terminal remote control APP signs the latest whitelist characteristic value, and locally saves the whitelist characteristic value and its signature.
  • the new key is used to re-issue the authorization token and the whitelist, which ensures the safe use of the authorization token and the whitelist.
  • the authorization token and blacklist can also be reissued with a new key to ensure the safe use of the authorization token and blacklist.
  • Figure 16 is a long-term authorization token validity verification flow chart 1600 provided by the embodiment of this application.
  • Figure 16 adds step S1604 on the basis of the original Figure 8, that is, verifying whether the authorization token ID is in the long-term authorization token ID list middle.
  • the specific steps performed by the method 1600 are as follows.
  • step S1602. verify the consistency between the remote control command issued by the device management system and the authorized object ID (AUTHORIZED_OBJ_ID), and if they are consistent, go to step S1602. If the verification fails, the remote control process ends.
  • AUTHORIZED_OBJ_ID the authorized object ID
  • step S1602 if the ID of the controlled object is consistent with the remote device identifier, go to step S1602; if not, the verification fails, and the remote control process ends.
  • the validity of the verification token time can be determined by judging whether the current time of the system satisfies a preset range.
  • the time validity verification can be passed. Otherwise, the verification fails, and the remote control process ends.
  • the time validity verification is passed. Otherwise, the verification fails, and the remote control process ends.
  • step S1604 check whether the authorization token ID is in the authorization token ID list 1115 of the long-term authorization token white list 1000, if it is in the list, go to step S1605, if not in the list, then the verification fails.
  • the remote device signature verification key distributed in advance can be obtained through the issuer ID 721 and the signature algorithm 731. If the remote signature verification key has been configured, go to step S1606. If the verification fails, the remote control process ends.
  • verification can be performed through the following steps.
  • Input authorization token, remote device signature verification key
  • the above-mentioned embodiment provides that in the remote control application, in order to support the invalidation and revocation of the authorization token, the scheme of signing the long-term task authorization token whitelist is adopted. Only the authorized tokens in the whitelist are valid, and it supports remote control solutions in scenarios such as periodic control, reservation control, and authorization management.
  • the remote control token method can be used alone or in combination with the long-term authorization token whitelist method.
  • the long-term authorization token blacklist method can be used alone, and can also be used in combination with the long-term authorization token whitelist method, and so on.
  • Fig. 17 is a remote control device 1700 provided by an embodiment of the present application.
  • the device can be applied to the remote control system 100 in FIG. 1 , and can also be applied to the remote control system 1000 in FIG. 10 .
  • the apparatus 1700 may include a transceiver unit 1710 , an acquisition unit 1720 and a processing unit 1730 .
  • the transceiver unit 1710 can implement a corresponding communication function, and the transceiver unit 1710 can also be called a communication interface or a communication unit.
  • the obtaining unit 1720 may be used to obtain corresponding instructions and/or data, and the processing unit 1730 is used to perform data processing.
  • the processing unit 1730 can read instructions and/or data in the storage unit, so that the device implements the aforementioned method embodiments.
  • the apparatus 2000 may further include a storage unit, which may be used to store instructions and/or data.
  • a storage unit which may be used to store instructions and/or data.
  • the apparatus 1700 is used to execute the actions performed by the terminal device or the terminal remote control APP in the above method embodiments.
  • the apparatus 1700 includes: an acquisition unit 1720 and a transceiver unit 1710; the acquisition unit 1720 is used to acquire an authorization token, and the authorization token includes authorization token content and authorization token signature information; Unit 1710: configured to send first request information to the device management system, where the first request information includes an operation request and an authorization token.
  • the operation request is used to request the device management system to issue a remote control command to the remote device, and the authorization token is used to cooperate with the legality verification of the remote control command.
  • the content of the authorization token includes: at least one item of token ID, issuer ID, authorized object ID, authorized content list, issuance time, validity period start time, and validity period end time.
  • the authorization content list includes: at least one of the controlled object identifier, operation, and key parameters;
  • the authorization token signature information includes: signature data or, signature data and signature algorithm.
  • the first request information further includes: a whitelist, the whitelist includes: whitelist content and whitelist signature information; the whitelist content includes: whitelist ID, issuer ID, At least one of authorized object identification, controlled object, authorization token ID list, and issuance time; the whitelist signature information includes: signature data or, signature data and signature algorithm.
  • the acquiring unit 1720 is further configured to: acquire a whitelist; the device further includes a processing unit 1730 configured to validate the whitelist; the processing unit 1730 is specifically configured to verify at least one of the following: Item: Verify whether the whitelist issuer is valid, verify whether the whitelist authorized object is valid, verify whether the whitelist control object is valid, and verify whether the whitelist signature is consistent.
  • the device further includes a storage unit, configured to store whitelist characteristic values; the processing unit 1730 is further configured to: use the whitelist characteristic values to verify the validity of the whitelist.
  • the acquiring unit 1720 is further configured to: acquire the characteristic value of the whitelist
  • the processing unit 1730 is specifically configured to: verify the characteristic value of the whitelist, and if the verification is passed, the storage unit is used to Save the whitelist characteristic value.
  • the whitelist characteristic value is a signed and/or encrypted whitelist characteristic value.
  • the processing unit is further configured to perform signature verification and/or decryption on the whitelist characteristic value.
  • the processing unit in the device is also used for 1730: generating authorization token content, and issuing the authorization token; determining the type of task operated by the user; determining the type of task operated by the user Whether to issue new authorization tokens and whether to update said whitelist.
  • the processing unit 1730 in the device is also used to update the key; re-issue the whitelist and authorization token with the updated key; the transceiver unit 1710 is also used to send the third Request information, the third request information includes the re-issued whitelist and authorization token.
  • the apparatus 1700 is used to execute the actions executed by the equipment management system in the above method embodiments.
  • the device includes a transceiver unit 1710 and a processing unit 1730; the transceiver unit is configured to 1710: receive first request information, where the first request information includes an operation request and an authorization token; the processing The unit 1730 is configured to: generate a remote control instruction according to the operation request, where the remote control instruction is used to instruct the remote device to execute the operation request.
  • the transceiver unit 1710 is further configured to: send second request information to the remote device, where the second request information includes the remote control instruction and an authorization token, and the authorization token is used to cooperate with the Verify the legitimacy of the above remote control commands.
  • the device includes a storage unit, and the storage unit is used to: save the authorization token and the white list; the processing unit 1730 is also used to update the white list, and the transceiver unit 1710 is also used to send The remote device sends the updated whitelist.
  • the apparatus 1700 is configured to perform the actions performed by the remote device in the above method embodiments.
  • the device includes a transceiver unit 1710 and a processing unit 1730; the transceiver unit 1710 is configured to: receive second request information, where the second request information includes a remote control instruction and an authorization token; the The processing unit 1730 is configured to: verify the validity of the authorization token, and verify the validity of the remote control instruction if the authorization token is valid.
  • verifying the validity of the authorization token includes at least one of the following: verifying whether the device management system is consistent with the authorized object ID, verifying whether the controlled object ID is consistent with the remote device ID, verifying the time validity of the token, Verify whether the signature verification key of the token issuer has been configured on the remote device, and verify whether the digital signature of the authorization token is consistent.
  • verifying the legitimacy of the remote command includes at least one of the following: verifying whether the remote device identifier is consistent with the controlled object identifier in the authorization token, verifying whether the remote control instruction is within the allowed operating range of the authorization token, verifying Whether the key parameter is within the key parameter range of the authorization token.
  • the second request information includes a whitelist
  • the processing unit 1730 is specifically configured to: verify whether the authorization token ID is in the whitelist ID list.
  • the second request information includes a blacklist
  • the processing unit 1730 is specifically configured to: verify whether the authorization token ID is in the blacklist ID list.
  • the processing unit 1730 is further configured to: verify the validity of the whitelist.
  • the processing unit 1730 is specifically configured to: verify the consistency of the remote device identifier and the controlled object identifier in the whitelist, verify whether the whitelist issuance time is less than or equal to the first threshold, and verify the consistency of the whitelist signature.
  • the processing unit 1730 is further configured to: determine a whitelist characteristic value according to the whitelist, where the whitelist characteristic value is used to identify the whitelist.
  • the processing unit 1730 is further configured to sign and/or encrypt the whitelist characteristic value; the transceiver unit 1710 is configured to send the signed and/or encrypted whitelist characteristic value to the terminal device.
  • processing unit in FIG. 17 can be realized by at least one processor or processor-related circuits
  • the acquisition unit and the transceiver unit can be realized by transceivers or transceiver-related circuits
  • the storage unit can be realized by at least one memory.
  • FIG. 18 is a schematic diagram of a remote control device 1800 provided by an embodiment of the present application.
  • the device can be applied to the remote control system 100 in FIG. 1 , and can also be applied to the remote control system 1000 in FIG. 10 .
  • the remote control device includes: a memory 1810 , a processor 1820 , and a communication interface 1830 .
  • the memory 1810, the processor 1820, and the communication interface 1830 are connected through an internal connection path, the memory 1810 is used to store instructions, and the processor 1820 is used to execute the instructions stored in the memory 1820 to control the input/output interface 1830 to receive/send At least some parameters of the second channel model.
  • the memory 1810 may be coupled to the processor 1820 through an interface, or may be integrated with the processor 1820 .
  • the above-mentioned communication interface 1830 uses a transceiver device such as but not limited to a transceiver to implement communication between the communication device 1800 and other devices or communication networks.
  • the above-mentioned communication interface 1830 may also include an input/output interface (input/output interface).
  • each step of the above method may be implemented by an integrated logic circuit of hardware in the processor 1820 or instructions in the form of software.
  • the methods disclosed in the embodiments of the present application may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.
  • the software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register.
  • the storage medium is located in the memory 1810, and the processor 1820 reads the information in the memory 1810, and completes the steps of the above method in combination with its hardware. To avoid repetition, no detailed description is given here.
  • the embodiment of the present application also provides a computer-readable medium, the computer-readable medium stores program codes, and when the computer program codes run on the computer, the computer executes any of the above-mentioned Figures 3 to 16. a way.
  • An embodiment of the present application also provides a chip, including: at least one processor and a memory, the at least one processor is coupled to the memory, and is used to read and execute instructions in the memory, so as to execute the above-mentioned steps in FIGS. Either method in Figure 16.
  • the embodiment of the present application also provides a vehicle, including: at least one processor and a memory, the at least one processor is coupled to the memory, and is used to read and execute the instructions in the memory, so as to execute the above-mentioned FIG. 3 to Either method in Figure 16.
  • the embodiment of the present application also provides a smart vehicle, including any remote control authorization token device in FIG. 17 or FIG. 18 .
  • the above-mentioned processor can be a central processing unit (central processing unit, CPU), and the processor can also be other general-purpose processors, digital signal processors (digital signal processor, DSP), dedicated integrated Circuit (application specific integrated circuit, ASIC), off-the-shelf programmable gate array (field programmable gate array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • a general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like.
  • the memory may include a read-only memory and a random access memory, and provide instructions and data to the processor.
  • a portion of the processor may also include non-volatile random access memory.
  • the processor may also store device type information.
  • serial numbers of the above-mentioned processes do not mean the order of execution, and the order of execution of the processes should be determined by their functions and internal logic, and should not be implemented in this application.
  • the implementation of the examples constitutes no limitation.
  • a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
  • an application running on a computing device and the computing device can be components.
  • One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers.
  • these components can execute from various computer readable media having various data structures stored thereon.
  • a component may, for example, be based on a signal having one or more packets of data (e.g., data from two components interacting with another component between a local system, a distributed system, and/or a network, such as the Internet via a signal interacting with other systems). Communicate through local and/or remote processes.
  • packets of data e.g., data from two components interacting with another component between a local system, a distributed system, and/or a network, such as the Internet via a signal interacting with other systems.
  • the disclosed systems, devices and methods may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit.
  • the functions described above are realized in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium.
  • the technical solution of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disc and other media that can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Selective Calling Equipment (AREA)

Abstract

本申请实施例提供了一种远程控制的方法和装置。该方法包括：远程设备从设备管理***接收第二请求信息，所述第二请求信息包括远控指令和授权令牌；所述远程设备验证所述授权令牌的有效性；所述远程设备在所述授权令牌有效的情况下，使用所述授权令牌验证所述远控指令的合法性。相对于传统的远程控制方法，本申请实施例能够对授权令牌和远控指令进行验证，验证远控指令是否在授权令牌范围内，以保证远控指令由用户授权，降低用户的隐私泄露和财产损失的风险。本申请实施例提供的方法或装置可应用于新能源汽车、智能汽车、智能家居等领域。

Description

远程控制的方法和装置 技术领域
本申请实施例涉及远程控制领域，并且更具体地，涉及一种远程控制过程中身份认证和鉴权的方法和装置。
背景技术
随着网络技术的演进和智能设备的普及，通过终端远程操控设备给使用者带来了诸多便利，远程控制能力已经成为智能设备的基础能力之一。在远程控制的过程中，终端可以通过部署在云端的设备管理***向远程设备(例如，智能车辆，智能家居等)发送远程控制指令，进而实现设备的智能化控制，使远程控制更加舒适和便捷。
在实现设备的智能化控制过程中，对远程控制***的安全性提出了更高的要求。目前，常用的远程控制安全方案，远程设备仅对设备管理***进行验证，但无法直接对操作人员(用户)的身份和操作意图进行验证，一旦设备管理***被攻击或者运维人员操作不合规定，通过设备管理***对远程设备实施攻击，导致用户的隐私、财产和生命安全受到侵犯。
发明内容
本申请实施例提供一种远程控制的方法和装置，通过终端用户签发授权令牌，远程设备对收到的授权令牌和远控指令进行验证，验证远控指令是否由合法用户发出或授权，是否在授权令牌范围内，以保证远控指令由用户授权，降低用户的隐私泄露和财产损失的风险。
第一方面，提供了一种远程控制的方法，该方法包括：远程设备从设备管理***接收第二请求信息，第二请求信息包括远控指令和授权令牌；远程设备验证所述授权令牌的有效性；远程设备在所述授权令牌有效的情况下，使用所述授权令牌验证远控指令的合法性。
可选地，授权令牌内容包括：令牌ID、签发者标识、被授权对象标识、授权内容列表、签发时间、有效期开始时间、有效期结束时间中的至少一项；授权内容列表包括：被控制对象标识、操作、关键参数中的至少一项；所述授权令牌签名信息包括签名数据，或所述授权令牌签名信息包括签名数据和签名算法。
具体地，授权令牌内容和签名可以根据实际的需要进行变化，例如，授权令牌可以由授权令牌内容所有内容中的部分内容组成。又例如，授权令牌签名可以仅包含签名数据。又例如，授权令牌可以附加二次令牌签名等额外的加密措施等等。
本申请实施例中，生成的授权令牌可以根据实际的需求灵活调整授权令牌内容，以适应不同的授权令牌应用场景，此外，可以对生成的授权令牌进行签名和/或加密的方式 保障授权令牌的使用安全。
可选地，验证授权令牌的有效性包括以下内容至少一项：验证设备管理***与被授权对象标识是否一致、验证被控制对象ID与远程设备标识是否一致、验证令牌的时间有效性、验证令牌签发者的验签密钥是否已经在远程设备端配置、验证授权令牌数字签名是否一致。
可选地，验证远程指令的合法性包括以下内容至少一项：验证远程设备标识与授权令牌中的被控制对象标识是否一致、验证远控指令是否在授权令牌的允许操作范围内、验证关键参数是否在授权令牌的关键参数范围内。
本申请实施例中，远程设备可以对接收到的授权令牌进行有效性验证，在有效性验证通过后使用授权令牌验证远控指令的合法性，只有在两项验证都通过的情况下远程设备才执行远控指令。通过这样的方式，可以保证远控指令与设备拥有者/授权者意图一致，降低用户的隐私泄露和财产损失的风险。
具体地，传统的远程控制方案用户可以通过设备管理***直接或间接的向远程设备下发命令，控制远程设备工作。但是在传统的远程控制方案中，由于远程设备仅对设备管理***进行验证，但无法直接对操作人员(用户)的身份和操作意图进行验证，换句话说，远程设备无法确认接收到的远程控制指令是否得到用户授权。一旦设备管理***被攻击或者运维人员操作不合规定，可能使远程设备遭受攻击，导致用户的隐私、财产和生命安全受到侵犯。
例如，设备管理***可能受到黑客的攻击。黑客入侵设备管理***，可以窃取并篡改用户的远程控制指令。由于远程设备无法识别远控指令是否得到用户的授权，一旦远程设备执行经黑客篡改后的远控指令，会使用户的财产遭受损失。
又例如，设备管理***的运维人员可能因超出其职责范围的操作，导致远控指令不符合用户的操作意图，由于远程设备无法识别远控指令是否满足用户的授权范围，一旦远程设备执行了不符合用户操作意图的远控指令，会使用户的隐私、财产安全得不到保障。
本申请实施例采用远控指令和授权令牌共同传递的方式，远程设备在接收到远控指令和授权令牌后，需要使用授权令牌对远控指令进行验证，验证远控指令是否在授权令牌范围内，以保证远控指令由用户授权，避免了因运维人员不合规定操作，带来的对远程设备安全性的威胁。
结合第一方面，在第一方面的某些实现方式中，第二请求信息中还包括白名单，所述验证授权令牌的有效性还包括：验证授权令牌ID是否在白名单ID列表中。
结合第一方面，在第一方面的某些实现方式中，第二请求信息中还包括黑名单，所述验证授权令牌的有效性还包括：验证授权令牌ID是否在黑名单ID列表中。
具体地，当远程控制涉及长期任务时，长期任务的特征是任务可能被取消，此时，授权令牌也需要同步被吊销，这就需要通过一种机制来保证被吊销的授权令牌不被非法使用。本申请实施例中通过部署白名单的方式，可以配合授权令牌的有效性验证，其中，白名单方案也可以替换成黑名单方案，在黑名单中列出已经被吊销的令牌，来保证授权令牌的使用安全。
本申请实施例中，可以在签署授权令牌的同时发布白名单，在授权令牌验证通过的基础上再判断授权令牌ID是否在白名单ID列表中，来保证授权令牌未被吊销。授权令牌只有通过了白名单验证才能被使用。也可以在签署授权令牌的同时发布黑名单，在授权令牌验证通过的基础上再判断授权令牌ID是否在黑名单ID列表中，授权令牌ID只有不在黑名单的列表中才能被使用。通过上述方式，可以保证授权令牌未被吊销，降低用户的隐私泄露和财产损失的风险。
结合第一方面，在第一方面的某些实现方式中，所述方法还包括：远程设备验证所述白名单的有效性。
本申请实施例中，可以在发布白名单的同时，验证白名单的有效性。只有在白名单有效的情况下才使用该白名单验证授权令牌的有效性，可以保证白名单的安全使用，降低用户的隐私泄露和财产损失的风险。
结合第一方面，在第一方面的某些实现方式中，验证白名单的有效性包括以下内容至少一项：验证远程设备标识与白名单中被控制对象标识的一致性、验证白名单签发时间是否小于或等于第一阈值、验证白名单签名的一致性。
具体的，验证白名单签发时间是否小于或等于第一阈值可以指判断白名单的签发时间是否在远程设备***当前时间差允许的范围内。其中，第一阈值代表远程设备***当前时间差允许的最大值，其数值可以根据实际情况预先设定。
例如，设定远程设备***当前时间差允许的范围为10秒以内，当白名单签发时间为8秒时，白名单的签发时间满足要求。当白名单签发时间为12秒时，白名单签发时间不满足要求，白名单更新失败。
验证白名单签名的一致性可以指利用密钥对白名单签名的有效性进行验证，如果白名单的签名和密钥一致，则签名验证成功；如果白名单签名和密钥不一致，则签名验证失败，白名单更新失败。
本申请实施例中，可以对发布白名单进行有效性验证，通过验证白名单被控对象与远程设备标识的一致性、验证白名单验证白名单签发时间是否小于或等于第一阈值以及验证白名单签名的一致性的方式保证白名单不被攻击，可以降低用户的隐私泄露和财产损失的风险。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：远程设备根据所述白名单确定白名单特征值；所述远程设备对所述白名单特征值进行签名和/或加密；所述远程设备向终端设备发送经过签名和/或加密后的白名单特征值。
其中，白名单的特征值中记载了白名单的关键信息或指纹信息，在某些场景下可以起到代替白名单的作用，并且白名单特征值占用设备的空间小，可以降低手机等设备的存储开销。此外，远程设备可以通过对白名单特征值签名和/或加密的方式，进一步保障白名单特征值的使用安全。
获取白名单特征值可以采用不同的方式，例如，可以通过一些算法或函数从白名单中摘要一些关键信息(关键字段、字节等)来获取白名单的特征值，具体地，可以通过Hash函数对白名单中的关键信息进行处理，生成Hash函数值，并将Hash函数值作为白名单特征值使用。又例如，可以将白名单ID作为白名单特征值进行使用。
本申请实施例中，提出了白名单的特征值机制，远程设备从白名单中可以获取白名单的特征值。由于白名单的特征值中记载了白名单的关键信息或指纹信息，在某些场景下可以起到代替白名单的作用，并且白名单特征值占用设备的空间小，可以降低手机等设备的存储开销。此外，远程设备可以通过对白名单特征值签名和/或加密的方式，进一步保障白名单特征值的使用安全。
第二方面，提供了一种远程控制的方法，该方法包括：终端设备获取授权令牌；向设备管理***发送第一请求信息，所述第一请求信息包括操作请求和所述授权令牌；所述操作请求用于请求所述设备管理***向远程设备下发远控指令，所述授权令牌用于执行所述远控指令的合法性验证。
可选地，授权令牌内容包括：令牌ID、签发者标识、被授权对象标识、授权内容列表、签发时间、有效期开始时间、有效期结束时间中的至少一项；授权内容列表包括：被控制对象标识、操作、关键参数中的至少一项；所述授权令牌签名信息包括签名数据，或所述授权令牌签名信息包括签名数据和签名算法。
本申请实施例中，可以在第一请求信息中携带授权令牌和用户的操作请求，设备管理***会根据用户的操作请求向远程设备下发远控指令，授权令牌用于执行远控指令的合法性验证，验证远控指令是否在授权令牌范围内，以保证远控指令由用户授权，降低用户的隐私泄露和财产损失的风险。
结合第二方面，在第二方面的某些实现方式中，所述第一请求信息还包括：白名单，所述白名单包括：白名单内容和白名单签名信息；所述白名单内容包括：白名单ID、签发者标识、被授权对象标识、被控制对象、授权令牌ID列表、签发时间中的至少一项；所述白名单签名信息包括签名数据或，所述白名单签名信息包括签名数据和签名算法。
其中，可以根据实际的需求灵活调整白名单内容，以适应不同的白名单应用场景，例如，白名单可以包括白名单所有内容中的部分内容，又例如，可以对白名单的签名数据进行加密，以保证白名单的使用安全。
本申请实施例中，为了支持长期任务授权令牌的使用，通过在第一请求信息中部署白名单的方式，便于后续远程设备验证授权令牌内容是否在白名单内，保障了授权令牌的使用安全。
结合第二方面，在第二方面的某些实现方式中，该方法还包括：终端设备获取白名单，并验证所述白名单的有效性；所述验证所述白名单的有效性包括以下内容中的至少一项：验证白名单签发者是否有效、验证白名单被授权对象是否有效、验证白名单控制对象是否有效、验证白名单签名是否一致。
本申请实施例中，终端设备可以获取白名单并对白名单有效性进行验证，只有在白名单的有效性验证通过的情况下才使用该白名单，保障了白名单的使用安全性。
结合第二方面，在第二方面的某些实现方式中，该方法还包括：终端设备保存白名单特征值；所述验证所述白名单的有效性包括：所述终端设备使用所述白名单特征值，验证所述白名单的有效性。
本申请实施例中，终端设备可以预先保存白名单的特征值，并且使用预先保存的白名单特征值对白名单的有效性进行验证，只有在白名单的有效性验证通过的情况下才使 用该白名单，保障了白名单的使用安全性。
结合第二方面，在第二方面的某些实现方式中，所述方法还包括：终端设备从远程设备获取所述白名单特征值；所述终端设备对所述白名单特征值进行验证，若通过所述验证，所述终端保存所述白名单特征值。
本申请实施例中，可以使用预先保存的白名单特征值对从远程设备获取的特征值进行验证，如果特征值一致，则验证通过，终端设备保存验证通过的白名单特征值。通过这种方式，可以防止获取的白名单特征值被非法替换。
结合第二方面，在第二方面的某些实现方式中，白名单特征值为经过签名和/或加密的白名单特征值。
结合第二方面，在第二方面的某些实现方式中，所述终端设备对所述白名单特征值进行验证还包括：对白名单特征值进行验签和/或解密。
本申请实施例中，终端设备接收到经过签名和/或加密的白名单特征值后，可以对白名单特征值的签名进行验签，和/或对白名单特征值的加密进行解密，由此，可以提高白名单特征值的使用安全性。
结合第二方面，在第二方面的某些实现方式中，该方法还包括：终端设备根据用户的操作生成授权令牌内容，并签发所述授权令牌；所述终端设备确定用户操作的任务类型；所述终端设备根据用户操作的任务类型，确定是否签发新授权令牌和是否更新所述白名单。
本申请实施例中，可以根据用户的操作按需签发授权令牌。并且，可以根据用户操作的任务类型来决定是否签发新令牌，以及是否更新白名单。可以使授权令牌适用长期授权场景，保证授权令牌安全使用。
结合第二方面，在第二方面的某些实现方式中，该方法还包括：更新密钥；终端设备用更新后的密钥重新签发白名单和授权令牌；向设备管理***发送第三请求信息，该第三请求信息包括所述重新签发的白名单和授权令牌。
可选地，在用更新后的密钥重新签发白名单和授权令牌之前，该步骤中还可以包括用更新前的密钥验证白名单和授权令牌的有效性。
本申请实施例中，在密钥需要更新的场景下，通过使用更新后的密钥对授权令牌和白名单进行重新签发方式，保证了授权令牌和白名单的安全使用。
第三方面，提供了一种远程控制的方法，该方法包括：接收第一请求信息，该第一请求信息包括操作请求和授权令牌；根据所述操作请求生成远控指令，所述远控指令用于指示远程设备执行所述操作请求。
结合第三方面，在第三方面的某些实现方式中，该方法还包括：向远程设备发送第二请求信息，所述第二请求信息包括远控指令和授权令牌，所述授权令牌用于验证所述远控指令的合法性。
本申请实施例中，设备管理***对接收到的用户的不同操作请求进行处理，生成对应的远控指令，并将操作指令和授权令牌发送给远程设备，便于远程设备使用授权令牌对远控指令的合法性进行验证，以实现用户的远程控制。
第四方面，提供了一种远程控制方法，该方法包括：远程设备从设备管理***接收 第二请求信息，所述第二请求信息包括白名单。所述远程设备对所述白名单的有效性进行验证。
结合第四方面，在第四方面的某些实现方式中，所述白名单的有效性验证包括以下内容至少一项：验证远程设备标识与白名单中的被控制对象标识的一致性、验证白名单签发时间是否小于或等于第一阈值、验证白名单签名的一致性。
结合第四方面，在第四方面的某些实现方式中，所述方法还包括，远程设备根据所述白名单确定白名单特征值，所述白名单特征值用于标识所述白名单；所述远程设备对所述白名单特征值进行签名和/或加密；所述远程设备向终端设备发送经过签名和/或加密后的白名单特征值。
第五方面，提供了一种远程控制方法，该方法包括：终端设备获取白名单，并验证所述白名单的有效性；所述验证所述白名单的有效性包括：验证白名单签发者是否有效、验证白名单被授权对象是否有效、验证白名单控制对象是否有效、验证白名单签名是否一致中的至少一项。
结合第五方面，在第五方面的某些实现方式中，该方法包括：终端设备保存白名单特征值；所述验证所述白名单的有效性包括：所述终端设备使用所述白名单特征值，验证所述白名单的有效性。
结合第五方面，在第五方面的某些实现方式中，该方法包括：终端设备从远程设备获取所述白名单特征值；所述终端设备对所述白名单特征值进行验证，若通过所述验证，所述终端保存所述白名单特征值。
结合第五方面，在第五方面的某些实现方式中，白名单特征值为经过签名和/或加密的白名单特征值。
结合第五方面，在第五方面的某些实现方式中，所述终端设备对所述白名单特征值进行验证还包括：对白名单特征值进行验签和/或解密。
本申请实施例中，终端设备接收到经过签名和/或加密的白名单特征值后，可以对白名单特征值的签名进行验签，和/或对白名单特征值的加密进行解密，由此，可以提高白名单特征值的使用安全性。
结合第五方面，在第五方面的某些实现方式中，所述方法还包括：终端设备根据用户的操作生成授权令牌内容，并签发所述授权令牌；所述终端设备确定用户操作的任务类型；所述终端设备根据所述用户操作的任务类型，确定是否签发新授权令牌和是否更新所述白名单。
结合第五方面，在第五方面的某些实现方式中，所述方法还包括：终端设备向设备管理***发送第一请求信息，所述第一请求信息包括：任务请求、授权令牌和白名单。
结合第五方面，在第五方面的某些实现方式中，所述白名单包括：白名单内容和白名单签名信息；所述白名单内容包括：白名单ID、签发者标识、被授权对象标识、被控制对象、授权令牌ID列表、签发时间中的至少一项；所述白名单签名信息包括签名数据或，所述白名单签名信息包括签名数据和签名算法。
结合第五方面，在第五方面的某些实现方式中，所述方法还包括更新密钥；终端设备使用更新后的密钥重新签发所述白名单和所述授权令牌；所述终端设备向设备管理系 统发送第三请求信息，所述第三请求信息包括所述重新签发的白名单和授权令牌。
第六方面，提供了一种远程控制装置，该装置包括收发单元和处理单元；所述收发单元用于：接收第二请求信息，所述第二请求信息包括远控指令和授权令牌；所述处理单元用于：验证所述授权令牌的有效性，若所述授权令牌有效，使用所述授权令牌验证所述远控指令的合法性。
结合第六方面，在第六方面的某些实现方式中，所述处理单元具体用于验证以下内容至少一项：验证设备管理***与被授权对象标识是否一致、验证被控制对象ID与远程设备标识是否一致、验证令牌的时间有效性、验证令牌签发者的验签密钥是否已经在远程设备端配置、验证授权令牌数字签名是否一致。
结合第六方面，在第六方面的某些实现方式中，所述处理单元具体用于验证以下内容至少一项：验证远程设备标识与授权令牌中的被控制对象标识是否一致、验证远控指令是否在授权令牌的允许操作范围内、验证关键参数是否在授权令牌的关键参数范围内中的至少一项。
结合第六方面，在第六方面的某些实现方式中，所述第二请求信息中包括黑名单，所述处理单元具体于：验证授权令牌ID是否在黑名单ID列表中。
结合第六方面，在第六方面的某些实现方式中，所述第二请求信息中包括白名单，所述处理单元具体用于：验证授权令牌ID是否在白名单ID列表中。
结合第六方面，在第六方面的某些实现方式中，所述处理单元还用于验证所述白名单的有效性。
结合第六方面，在第六方面的某些实现方式中，所述处理单元具体用于验证以下内容至少一项：验证白名单被控对象与远程设备标识的一致性、验证白名单签发时间是否小于或等于第一阈值、验证白名单签名的一致性。
结合第六方面，在第六方面的某些实现方式中，所述处理单元还用于：根据所述白名单确定白名单特征值，所述白名单特征值用于标识所述白名单；所述处理单元还用于对所述白名单特征值进行签名和/或加密；所述收单元还用于：发送经过签名和/或加密后的白名单特征值。
第七方面，提供了一种远程控制的装置，该装置包括：获取单元和收发单元；获取单元：用于获取授权令牌，收发单元：用于向设备管理***发送的第一请求信息，所述第一请求信息包括操作请求和授权令牌。所述操作请求用于请求所述设备管理***向远程设备下发远控指令，所述授权令牌用于执行所述远控指令的合法性验证。
结合第七方面，在第七方面的某些实现方式中，所述授权令牌包括授权令牌内容和授权令牌签名信息；所述授权令牌内容包括：令牌ID、签发者标识、被授权对象标识、授权内容列表、签发时间、有效期开始时间、有效期结束时间中的至少一项。所述授权内容列表包括：被控制对象标识、操作、关键参数中的至少一项；所述授权令牌签名信息包括签名数据，或所述授权令牌签名信息包括签名数据和签名算法。
结合第七方面，在第七方面的某些实现方式中，所述第一请求信息还包括：白名单，所述白名单包括：白名单内容和白名单签名信息；所述白名单内容包括：白名单ID、签发者标识、被授权对象标识、被控制对象、授权令牌ID列表、签发时间中的至少一项； 所述白名单签名信息包括：签名数据或，所述白名单签名信息包括签名数据和签名算法。
结合第七方面，在第七方面的某些实现方式中，获取单元还用于：获取白名单；该装置还包括处理单元，用于验证所述白名单的有效性；所述处理单元具体用于验证以下内容至少一项：验证白名单签发者是否有效、验证白名单被授权对象是否有效、验证白名单控制对象是否有效、验证白名单签名是否一致。
结合第七方面，在第七方面的某些实现方式中，该装置还包括存储单元，用于保存白名单特征值，所述白名单特征值用于标识所述白名单；处理单元还用具体于：使用所述白名单特征值，验证所述白名单的有效性。
结合第七方面，在第七方面的某些实现方式中，收发单元还用于从远程设备获取白名单特征值；处理单元还用于对所述白名单特征值进行验证，若通过所述验证，存储单元保存所述白名单特征值。
结合第七方面，在第七方面的某些实现方式中，所述白名单特征值为经过签名和/或加密的白名单特征值。
结合第七方面，在第七方面的某些实现方式中，所述处理单元还用于对白名单特征值进行验签和/或解密。
结合第七方面，在第七方面的某些实现方式中，该装置中的处理单元还用于：生成授权令牌内容，并签发所述授权令牌；确定用户操作的任务类型；根据所述用户操作的任务类型，确定是否签发新授权令牌和是否更新所述白名单。
结合第七方面，在第七方面的某些实现方式中，该装置中的处理单元还用于更新密钥；用更新后的密钥重新签发白名单和授权令牌；收发单元还用于向设备管理***发送第三请求信息，所述第三请求信息包括所述重新签发的白名单和授权令牌。
第八方面，提供了一种远程控制的授权令牌装置，该装置包括收发单元和处理单元；所述收发单元用于：接收第一请求信息，所述第一请求信息包括操作请求和授权令牌；所述处理单元用于：根据所述操作请求，生成远控指令，所述远控指令用于指示远程设备执行所述操作请求。
结合第八方面，在第八方面的某些实现方式中，所述收发单元还用于：向远程设备发送第二请求信息，所述第二请求信息包括所述远控指令和授权令牌，所述授权令牌用于执行所述远控指令的合法性验证。
第九方面，提供一种远程控制的授权令牌装置，该装置包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，该装置用于执行上述各个方面中的方法。
第十方面，提供一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各个方面中的方法。
第十一方面，提供一种芯片，该芯片包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，该装置用于执行上述各个方面中的方法。
第十二方面，提供一种车辆，该车辆包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，该车辆中的处理器用 于执行上述各个方面中的方法。
附图说明
图1是本申请实施例提供的一种远程控制***100。
图2是本申请实施例提供的远程设备的示意图。
图3是本申请实施例提供的一种远程控制方案。
图4是本申请实施例提供的另一种远程控制方案。
图5是本申请实施例提供的一种远程控制的方法500。
图6是本申请实施例提供的一种授权令牌签发和鉴权流程图600。
图7是本申请实施例提供的一种授权令牌结构700。
图8是本申请实施例提供的一种授权令牌有效性验证流程图800。
图9是本申请实施例提供的一种远控指令合法性验证流程图900。
图10是本申请实施例提供的另一种远程控制***1000。
图11是本申请实施例提供的一种长期任务授权令牌白名单结构1100。
图12是本申请实施例提供的一种长期任务授权令牌白名单签发流程图1200。
图13是本申请实施例提供的一种终端设备的白名单有效性流程图1300。
图14是本申请实施例提供的一种远程设备的白名单更新有效性验证流程图1400。
图15是本申请实施例提供的一种授权令牌重新签发流程图1500。
图16是本申请实施例提供的一种长期授权令牌有效性验证流程图1600。
图17是本申请实施例提供的一种远程控制装置1700。
图18是本申请实施例提供的另一种远程控制装置1800。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
为了便于理解本申请实施例，首先本申请实施例所用术语进行介绍。
(1)APP：应用程序(Application，APP)指的是智能手机等终端设备上的应用程序。
(2)GNSS：全球导航卫星***(global navigation satellite system,GNSS)是指能在地球表面或近地空间的任何地点为用户提供全天候的三维坐标和速度以及时间信息的空基无线电导航定位***。
(3)MAC：消息认证码(message authentication code，MAC)是指经过特定算法后产生的一小段信息，检查某段消息的完整性，以及作身份验证。它可以用来检查在消息传递过程中，其内容是否被更改过，不管更改的原因是来自意外或是蓄意攻击。同时可以作为消息来源的身份验证，确认消息的来源。
(4)DTLS:数据包传输层安全性协议(datagram transport layer security,DTLS)是对现存的安全传输层协议(transport layer security，TLS)协议架构上提出扩展，使之支持用户数据报协议(User Datagram Protocol,UDP)，即成为TLS的一个支持数据包传输的版本。
(5)IOT:物联网(internet of things，IOT)是一种计算设备、机械、数字机器相互关系的***，具备通用唯一识别码并具有通过网络传输数据的能力，无需人与人、或是 人与设备的交互。物联网将现实世界数字化，应用范围十分广泛
(6)长期任务授权令牌：授权令牌有效期长于一定门限的授权令牌定义为长期任务授权令牌。满足以下条件即为长期任务授权令牌：令牌有效期结束时间(VALIDITY_EXIRATION_TIME)-签发时间(ISSUE_TIME)>＝长期授权令牌时长门限(可配置，如12小时)。
(7)长期任务授权令牌白名单：有效的长期任务授权令牌ID的集合，受签发者签名保护。长期任务授权令牌有效性验证在普通授权令牌有效性验证的基础上，还需要保证授权令牌ID在白名单内。
(8)远程设备：用户需要进行远程操控的设备，其可以是智能车辆，智能家居等等。
(9)授权令牌内容：指授权令牌上所承载的信息。
(10)Hash函数：是把任意长度的输入通过散列算法变换成固定长度的输出，该输出就是散列值。换句话说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。
图1是本申请实施例提供的一种远程控制***。
如图1所示，用户101可以是远程设备105的所有者或被授权者，被允许通过终端远控APP 102控制远程设备105。终端远控APP 102可以安装在手机等终端设备上，用户101可以通过APP 102远程查看、操作、管理远程设备105。设备管理***103可以部署在云上或服务器上，能支持终端远控APP 102和远程设备105的接入，并为他们提供服务。
具体的，设备管理***103由运营商或设备厂商的运维人员进行运维。远程设备105接入设备管理***103后，设备管理***103可以对远程设备105进行集中管理。在实际的工作过程中，用户101可以通过设备管理***103直接或间接的向远程设备105下发命令，控制远程设备105工作。
密钥管理***104负责给终端远控APP 102和远程设备105分发密钥。密钥管理***104可以是独立的***，也可以集成到设备管理***103中。密钥管理***104可以部署在云上，也可以部署在专用服务器上，本申请实施例对此不作限定。
远程设备105的设备拥有人或授权人员可以在近端操控该远程设备105，也可以通过终端远控APP 102远程操作该远程设备105。远程设备105可以直接由设备拥有人或授权人员直接管理。
其中，远程设备105可以是智能汽车或者智能家居等智能设备，当远程设备105为智能汽车时，设备管理***103下发的远程控制指令可以是开/关车门的指令，远程设备105收到开/关车门的指令后，可以执行该指令，以实现用户对车辆的车门开/关状态的远程控制。设备管理***103下发的指令也可以是打开/关闭车窗的指令，远程设备105收到关闭/打开车窗的指令，可以执行该指令，实现用户对车辆的车窗打开/关闭状态的远程控制。设备管理***103下发的指令还可以是开启/关闭车灯的指令，远程设备105收到开启/打开车灯的指令，可以执行该指令，以实现车辆车灯开启/关闭的远程控制。当远程设备105是智能家居时，设备管理***103下发的远程控制指令可以是打开/关闭窗帘的指令，远程设备105执行该指令后，用户可以远程控制家中窗帘的开启/关闭状态。设备 管理***103下发的远程控制指令还可以是开启/关闭音响，远程设备105执行该指令后，用户可以远程控制家中的音响的开启/关闭状态，进而控制音乐的播放。
时间同步***106可以为终端102、设备管理***103和远程设备105提供时间同步，以保证远程控制***100运行良好。其中，时间同步可以通过GNSS进行，也可以通过其他方式进行，本申请实施例对此不作限定。
通信链路107可以是终端远控APP 102与设备管理***103之间的通信链路。通过该链路，终端远控APP 102进入设备管理***103对远程设备105进行远程控制。设备管理***103可以对终端远控APP 102进行认证和鉴权，使两者间建立安全传输通道，例如HTTPS等，以保证通信安全。
通信链路108可以是远程设备105接入到设备管理***103的通信链路。设备管理***103可以通过该线路管理和控制远程设备105。远程设备105与设备管理***间进行认证和鉴权，建立安全传输通道，例如DTLS等，以保证通信安全。
用户签名密钥109可以由密钥管理***104分配，授权令牌签名可以采用对称密钥的消息认证码MAC或非对称密钥的数字签名算法等等。当授权令牌签名采用基于对称密钥的消息认证码MAC时，用户签名密钥109与远程设备验签密钥110相同，当授权令牌签名采用基于非对称密钥的数字签名算法时，用户签名密钥109是用户101的私钥。
远程设备验签密钥110可以由密钥管理***104分配，授权令牌签名可以采用对称密钥的消息认证码MAC或非对称密钥的数字签名算法等等。当授权令牌签名采用基于对称密钥的消息认证码MAC时，用户签名密钥109与远程设备验签密钥110相同，当授权令牌签名采用基于非对称密钥的数字签名算法时，用户签名密钥109是用户101的公钥。
图2是本申请实施例提供的远程设备的一个例子的示意图。如图2所示的车辆200可以是图1的远程设备105的一个例子。
车辆200可包括各种子***，例如计算平台210等，并且每个子***都可包括多个部件。
车辆200的部分或所有功能受计算平台210控制。计算平台210可包括至少一个处理器211，处理器211可以执行存储在例如存储器212这样的非暂态计算机可读介质中的指令213。在一些实施例中，计算平台210还可以是采用分布式方式控制车辆200的个体组件或子***的多个计算设备。
在一些实施例中，存储器212可包含指令213(例如，程序逻辑)，指令213可被处理器211执行来执行车辆200的各种功能。存储器212也可包含额外的指令，包括向其他子***中的一个或多个发送数据、从其接收数据、与其交互和/或对其进行控制的指令。
除了指令213以外，存储器212还可存储数据，例如道路地图、路线信息，车辆的位置、方向、速度以及其它这样的车辆数据，以及其他信息。这种信息可在车辆200在自主、半自主和/或手动模式中操作期间被车辆200和计算平台210使用。
计算平台210可基于从各种子***接收的输入来控制车辆200的功能。在一些实施例中，计算平台210可操作来对车辆200及其子***的许多方面提供控制。
可选地，上述这些组件中的一个或多个可与车辆200分开安装或关联。例如，存储 器212可以部分或完全地与车辆200分开存在。上述组件可以按有线和/或无线方式来通信地耦合在一起。
可选地，上述组件只是一个示例，实际应用中，上述各个模块中的组件有可能根据实际需要增添或者删除，图2不应理解为对本申请实施例的限制。
在道路行进的自动驾驶车辆，如上面的车辆200，可以识别其周围环境内的物体以确定对当前速度的调整。所述物体可以是其它车辆、交通控制设备、或者其它类型的物体。在一些示例中，可以独立地考虑每个识别的物体，并且基于物体的各自的特性，诸如它的当前速度、加速度、与车辆的间距等，可以用来确定自动驾驶车辆所要调整的速度。
可选地，车辆200或者与车辆200相关联的感知和计算设备(例如计算***211、计算平台210)可以基于所识别的物体的特性和周围环境的状态(例如，交通、雨、道路上的冰、等等)来预测所述识别的物体的行为。可选地，每一个所识别的物体都依赖于彼此的行为，因此还可以将所识别的所有物体全部一起考虑来预测单个识别的物体的行为。车辆200能够基于预测的所述识别的物体的行为来调整它的速度。换句话说，自动驾驶车辆能够基于所预测的物体的行为来确定车辆将需要调整到(例如，加速、减速、或者停止)什么稳定状态。在这个过程中，也可以考虑其它因素来确定车辆200的速度，诸如，车辆200在行驶的道路中的横向位置、道路的曲率、静态和动态物体的接近度等等。
除了提供调整自动驾驶车辆的速度的指令之外，计算设备还可以提供修改车辆200的转向角的指令，以使得自动驾驶车辆遵循给定的轨迹和/或维持与自动驾驶车辆附近的物体(例如，道路上的相邻车道中的轿车)的安全横向和纵向距离。
上述车辆200可以为轿车、卡车、摩托车、公共车辆、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车等，本申请实施例不做特别的限定。
目前，在常用的远程控制方案中，用户可以通过设备管理***直接或间接的向远程设备下发命令，控制远程设备工作。
图3是一种远程控制方案，图3的远程控制方案可应用于图1的远程控制***100中。
如图3所示，该远程控制方案可以分为两个阶段，即用户终端和设备管理***之间进行交互、以及设备管理***和远程设备之间进行交互。在该远程控制方案中，用户终端和设备管理***之间完成认证、鉴权以及通信链路安全保护。同时，设备管理***和远程设备间完成认证、鉴权以及通信链路安全保护。通过这种方式，用户可以通过设备管理***向远程设备下发命令，进而实现远程操控设备。
但是，此种方案可以安全运行的前提是设备管理***安全可信，即设备管理***本身是安全的，运维人员也是可信的。由于远程设备无法对设备管理***的安全性进行验证，也无法确认接收到的远程控制指令是否得到用户授权。一旦设备管理***被攻击或者运维人员操作不合规定，可能使远程设备遭受攻击，导致用户的隐私、财产和生命安全受到侵犯。
例如，设备管理***可能受到黑客的攻击。黑客入侵设备管理***，可以窃取并篡改用户的远程控制指令。由于远程设备无法识别远控指令是否得到用户的授权，一旦远程 设备执行经黑客篡改后的远控指令，会使用户的财产遭受损失。
又例如，设备管理***的运维人员可能因超出其职责范围的操作，导致远控指令不符合用户的操作意图，由于远程设备无法识别远控指令是否满足用户的授权范围，一旦远程设备执行了不符合用户操作意图的远控指令，会使用户的隐私、财产安全得不到保障。
图4是另一种远程控制方案，图4的远程控制方案可应用于图1的远程控制***100中。
如图4所示，在该远程控制方案中，用户终端与远程设备直接进行认证、鉴权以及通信链路加密。设备管理***仅作为通信链路的通道，不参与业务的处理。该远程控制方案由于设备管理***无需介入认证等处理过程，可以提高远程控制方案的灵活性，但是由于设备管理***无法主动触发运维，在用户控制远程设备时，该方案无法对控制命令和参数进行智能优化，也无法支持自动化管理能力。
可见，在图3和图4的远程控制方案中，无法达到远程控制***的安全性与灵活性的平衡。
本申请实施例提供一种远程控制方法，终端设备可以根据用户的操作内容签发受签名保护的授权令牌。在远程设备侧对授权令牌进行签名验证，验证远控指令是否在授权令牌范围内，以保证远控指令由用户授权。通过此种方式，可以保证设备管理***下发的远控指令与设备拥有者或授权管理者的意图一致；消减设备管理***被攻击，或因运维人员不合规定操作，带来的对远程设备安全性的威胁。
图5是本申请实施例提供的一种应用与远程控制的授权令牌方法500，该方法可应用于图1的远程控制***100中。该方法500可以包括如下步骤。
S501，获取授权令牌。
具体的，获取授权令牌可以采用多种不同的方式。
例如，该授权令牌可以从设备管理***(例如，图1中的设备管理***103)获取，在此种方式中，终端设备得到授权令牌为长期授权令牌，终端设备可以对该长期授权令牌的有效性进行验证。
又例如，该授权令牌可以由终端设备(例如，图1中的终端远控APP 102)生成。当授权令牌由终端设备生成时，生成授权令牌可以包括：生成令牌内容(TOKEN_CONTENT)和生成令牌签名(TOKEN_SIGNATURE)信息两个步骤。
其中，生成令牌签名信息包括生成签名数据(SIGNATURE)和生成令牌签名(TOKEN_SIGNATURE)两个步骤。
应理解，签名数据可以指生成令牌签名的所必要的数据，签名数据可以和签名算法组合得到令牌签名信息。
生成签名数据可以通过以下两种方法：
方法1：基于对称密钥的消息认证码MAC算法
输入：授权令牌内容(TOKEN_CONTENT)
用户签名密钥(MAC_KEY)
输出：签名数据(SIGNATURE_DATA)
处理过程：
SIGNATURE_DATA＝MAC(TOKEN_CONTENT,MAC_KEY)
应理解，MAC算法可以是HMAC、CMAC等安全消息认证码MAC，本申请实施例对此不作限定。
方法2：基于非对称密钥的数字签名算法
输入：授权令牌内容(TOKEN_CONTENT)
用户签名密钥(MAC_KEY)
输出：签名数据(SIGNATURE)
处理过程：
SIGNATURE_DATA＝Signature(TOKEN_CONTENT,MAC_KEY)
应理解，采用的数字签名的算法可以是RSA、DSA、ECDSA等业界通用算法，本申请实施例对此不做限定。
生成令牌签名信息可以通过如下公式：
TOKEN_SIGNATURE＝签名算法|SIGNATURE_DATA
生成授权令牌的主要由生成授权令牌内容和生成授权令牌信息签名两个步骤组合而成，即AUTHRIZATION_TOKEN＝TOKEN_CONTENT|TOKEN_SIGNATURE。
具体地，授权令牌内容可以包括：令牌ID、签发者标识、被授权对象标识、授权内容列表、签发时间、有效期开始时间、有效期结束时间中的至少一项。其中，授权列表可以包括：被控制对象标识、操作、关键参数中的至少一项。
其中，签发者标识是指用户的标识，远程设备可以根据该标识加载令牌签名的密钥；被授权对象标识是指设备管理***ID；被控制对象标识是指远程设备ID；操作是指远程控制的一个操作或具有相同安全等级的一类操作；关键参数是指远程控制涉及到用户生命和财产安全等核心利益的参数；签发时间是指授权令牌的签发时间；有效期开始时间是指授权令牌的有效期开始时间；有效期结束时间是指授权令牌的有效期结束时间。
授权令牌签名可以包括签名数据或，数据签名可以包括签名数据和签名算法。其中，签名算法是指对授权令牌进行加密所使用的算法；签名数据是指经过签名算法加密后所获得的数据结果。
其中，授权令牌内容和签名可以根据实际的需要进行变化，例如，授权令牌可以由授权令牌所有内容中的部分内容组成。又例如，授权令牌签名可以仅包含签名数据。又例如，授权令牌可以附加二次令牌签名等额外的加密措施等等。
应理解，授权令牌携带签名算法是考虑到***可以支持多种签名算法，如果***不能直接获取令牌所携带的算法，***需要花费时间进行核对，会导致浪费的资源，所以需要在授权令牌签名携带签名算法信息。在采用某种事先协商好的的签名算法，或通过信息获取采用的签名算法时，授权令牌也可以不携带签名算法。
本申请实施例中，生成的授权令牌可以根据实际的需求灵活调整授权令牌内容，以适应不同的授权令牌应用场景，此外，可以对生成的授权令牌进行签名和/或加密的方式保障授权令牌的使用安全。
一种可能的实现方式中，步骤S501中还可以包括获取白名单，并对白名单的有效性 进行验证。
当远程控制涉及长期任务时，长期任务的特征任务可能被取消，此时，授权令牌也需要同步被吊销，这就需要通过一种机制来保证被吊销的授权令牌不被非法使用。本申请实施例中通过部署白名单的方式，配合授权令牌的有效性验证，其中，白名单方案也可以替换成黑名单方案，在黑名单中列出已经被吊销的令牌，来保证授权令牌的使用安全。
具体地，白名单可以由白名单内容和白名单签名信息组成，白名单内容可以包括：白名单ID、签发者标识、被授权对象标识、被控制对象、授权令牌ID列表、签发时间中的至少一项；白名单签名信息可以包括：签名数据或，白名单签名信息可以包括签名数据和签名算法。
其中，白名单ID是指由用户签发的白名单唯一标识；签发这标识是指白名单签发者ID；授权令牌ID列表是指由用户签发的有效的授权令牌列表；签发时间是指白名单签发的时间。签名算法是指对白名单进行加密所使用的算法；签名数据是指经过签名算法加密后所获得的数据结果。
本申请实施例中，可以根据实际的需求灵活调整白名单内容，以适应不同的白名单应用场景，例如，白名单可以包括白名单所有内容中的部分内容，又例如，可以对白名单的签名数据进行加密，以保证白名单的使用安全。
一种可能的实现方式中，验证所述白名单的有效性可以包括验证以下内容至少一项：验证白名单签发者是否有效、验证白名单被授权对象是否有效、验证白名单控制对象是否有效、验证白名单签名是否一致。
本申请实施例中，为了支持长期任务授权令牌的使用或吊销，通过在第一请求信息中部署白名单的方式，便于后续远程设备验证授权令牌内容是否在白名单内，保障了授权令牌的使用安全。此外，终端设备可以获取白名单并对白名单有效性进行验证，只有在白名单的有效性验证通过的情况下才使用该白名单，保障了白名单的使用安全性。此外，白名单方案也可以替换为黑名单方案，可以对黑名单的有效性进行验证，在黑名单验证通过的基础上使用黑名单。
一种可能的实现方式中，步骤S501中还可以包括：终端设备保存白名单特征值；所述白名单特征值用于标识所述白名单，验证所述白名单的有效性包括：所述终端设备使用所述白名单特征值，验证所述白名单的有效性。
其中，白名单的特征值中记载了白名单的关键信息或指纹信息，在某些场景下可以起到代替白名单的作用，并且白名单特征值占用设备的空间小，可以降低手机等设备的存储开销。此外，远程设备可以通过对白名单特征值签名和/或加密的方式，进一步保障白名单特征值的使用安全。
一种可能的实现方式中，步骤S501中还可以包括：终端设备从远程设备获取所述白名单特征值；终端设备对所述白名单特征值进行验证，若通过所述验证，终端保存所述白名单特征值。
其中，获取白名单特征值可以采用不同的方式，例如，可以通过一些算法或函数从白名单中摘要一些关键信息(关键字段、字节等)来获取白名单的特征值，具体地，可以通过Hash函数对白名单中的关键信息进行处理，生成Hash函数值，并将Hash函数 值作为白名单特征值使用。又例如，可以将白名单ID作为白名单特征值进行使用。
本申请实施例中，终端设备可以仅保存白名单的特征值，避免了终端设备需要保存整个白名单列表，节省终端设备的存储开销。在白名单签发过程中，由远程设备反馈经过签名的白名单特征值。终端根据前一次获取的白名单计算出特征值，并与从远程设备侧接收到的特征值进行比较，如果一致说明分发过程中白名单没有被篡改，白名单有效。在白名单重新签发过程中，终端设备从设备管理***获取白名单，通过从获取到的白名单计算出特征值与终端设备本地保存的特征值比较，如果一致说明设备管理***中的白名单是最新的，该白名单有效。此外，白名单特征值也可以替换为黑名单特征值，在黑名单签发或重新签发的过程中使用黑名单特征值验证黑名单的有效性。
一种可能的实现方式中，步骤S501中白名单特征值为经过签名和/或加密的白名单特征值。
一种可能的实现方式中，步骤S501中还可以包括：终端设备根据用户的操作生成授权令牌内容，并签发所述授权令牌；终端设备确定用户操作的任务类型；根据用户操作的任务类型，确定是否签发新授权令牌和是否更新所述白名单。
表1给出根据用户操作的任务类型确定是否签发新令牌和是否更新白名单的一个示例性的例子。
表1
Figure PCTCN2021134045-appb-000001
按照表1的实现方式，当用户的操作指令涉及增加新的长期任务时，为了配合新增任务的指令传递，需要签发新的令牌，并在白名单中更新令牌的ID。通过此种方式，在白名单中携带了新任务的授权令牌ID，远程设备可以根据更新后的白名单和新授权令牌执行用户的操作命令。
在另一种情况下，当用户的操作指令涉及长期任务变更，并且该任务变更不涉及令牌内容调整时。由于不需要签发新的令牌，所以不需要对白名单进行更新。在后续的操作中，远程设备只需根据原来的白名单和授权令牌执行用户的变更操作命令。
在另一种情况下，当用户的操作指令涉及长期任务变更或删除任务，并且该任务变更涉及令牌内容调整时，为了配合变更任务的指令传递，需要签发新的令牌。此时，在白名单中需要删除老授权令牌的ID，增加新授权令牌的ID，以配合令牌内容的调整。
本申请实施例中，可以根据用户操作的任务类型来决定是否签发新令牌，以及是否更新白名单。可以使授权令牌适用长期授权场景，并保证授权令牌安全使用。此外，也可以根据用户操作的任务类型来决定是否签发新令牌，以及是否更新黑名单。使授权令牌适应不同应用场景。
一种可能的实现方式中，步骤S501中还可以包括：更新密钥；用新密钥重新签发 白名单和授权令牌；向设备管理***发送第三请求信息，第三请求信息包括重新签发的白名单和授权令牌。
具体的，在此种情形中，由于终端设备的对密钥进行了更新，所以需要对已经签发的授权令牌和白名单用更新后的密钥进行重新签发，并将重新签发的白名单和授权令牌发送给设备管理***。
可选地，在用更新后的密钥重新签发白名单和授权令牌之前，该步骤中还可以包括用更新前的密钥验证白名单和授权令牌的有效性。
本申请实施例中，在密钥需要更新的场景下，通过更新后的密钥对授权令牌和白名单进行重新签发方式，保证了授权令牌和白名单的安全使用。此外，也可以使用密钥对授权令牌和黑名单进行重新签发，使授权令牌适应不同应用场景。
S502，终端设备向设备管理***发送第一请求信息。
一种可能的实现方式中，该第一请求信息中包括操作请求和授权令牌。
其中，操作请求用于指示设备管理***向远程设备发送远程控制指令。授权令牌包括授权令牌内容和授权令牌签名信息，用于执行远控指令的合法性进行验证。
一种可能的实现方式中，该第一请求信息中还包括白名单。
一种可能的实现方式中，在第一请求信息中携带白名单之前，终端设备可以对白名单的有效性进行验证，在白名单的有效性验证通过的情况下，才在第一请求信息中携带该白名单。
本申请实施例中，为了支持长期任务授权令牌的使用，在涉及长期任务授权令牌变更时，需要通过在第一请求信息中部署白名单的方式，将白名单发送到远程设备，便于后续远程设备验证授权令牌内容是否在白名单内，防止被吊销的白名单被非法使用，保障了令牌的使用安全。此外，白名单也可以替换成黑名单，使授权令牌适应不同应用场景。
S503，设备管理***进行业务处理。
具体地，该步骤中设备管理***对接收到的用户的不同操作请求进行处理，生成对应的远控指令，并将操作指令发送给远程设备，进而实现用户的远程控制。
一种可能的实现方式中，该步骤中还包括设备管理***保存授权令牌和白名单。
具体地，设备管理***可以保存授权令牌和长期授权令牌白名单，供后续业务使用。
S504，设备管理***向远程设备发送第二请求信息。
具体地，第二请求信息中可以包括远控指令和授权令牌，远控指令用于指示远程设备执行对应的操作，授权令牌用于执行远控指令的合法性进行验证。
一种可能的实现方式中，第二请求信息中还可以包括白名单，该白名单发送给远程设备后，远程设备可以对该白名单进行更新。
S505，授权令牌的有效性验证，若授权令牌有效，则使用授权令牌验证远控指令的合法性。
具体地，验证令牌的有效性可以包括以下内容至少一项：验证设备管理***与被授权对象标识是否一致、验证被控制对象ID与远程设备标识是否一致、验证令牌的时间有效性、验证令牌签发者的验签密钥是否已经在远程设备端配置、验证授权令牌数字签名 是否一致。
具体地，验证远控指令的合法性可以包括以下内容至少一项：验证远程设备标识与授权令牌中的被控制对象标识是否一致、验证远控指令是否在授权令牌的允许操作范围内、验证关键参数是否在授权令牌的关键参数范围内中的。
本申请实施例中，可以对接收到的授权令牌进行有效性验证，在有效性验证通过后使用授权令牌验证远控指令的合法性，只有在两项验证都通过的情况下远程设备才执行远控指令。通过这样的方式，可以保证远控指令与设备拥有者/被授权者意图一致，降低用户的隐私泄露和财产损失的风险。
一种可能的实现方式中，第二请求信息中还可以包括白名单，验证令牌的有效性还包括：验证授权令牌ID是否在白名单ID列表中。
一种可能的实现方式中，第二请求信息中还可以包括黑名单，验证令牌的有效性还包括：验证授权令牌ID是否在黑名单ID列表中。
本申请实施例中，可以在签署授权令牌的同时发布白名单，在授权令牌验证通过的基础上再判断授权令牌ID是否在白名单ID列表中，来保证授权令牌未被吊销。授权令牌只有通过了白名单验证才能被使用。也可以在签署授权令牌的同时发布黑名单，在授权令牌验证通过的基础上再判断授权令牌ID是否在黑名单ID列表中，授权令牌ID只有不在黑名单的列表中才能被使用。通过上述方式，可以保证授权令牌未被吊销，降低用户的隐私泄露和财产损失的风险。
一种可能的实现方式中，在步骤S505中，还包括：验证白名单的有效性。验证白名单的有效性可以包括以下内容至少一项：验证远程设备标识与白名单中被控制对象标识的一致性、验证白名单签发时间是否小于或等于第一阈值、验证白名单签名的一致性。
具体的，验证白名单签发时间是否小于或等于第一阈值可以指判断白名单的签发时间是否在远程设备***当前时间差允许的范围内。其中，第一阈值代表远程设备***当前时间差允许的最大值，其数值可以根据实际情况预先设定。
例如，设定远程设备***当前时间差允许的范围为10秒以内，当白名单签发时间为8秒时，白名单的签发时间满足要求。当白名单签发时间为12秒时，白名单签发时间不满足要求，白名单更新失败。
验证白名单签名的一致性可以指利用密钥对白名单签名的有效性进行验证，如果白名单的签名和密钥一致，则签名验证成功；如果白名单签名和密钥不一致，则签名验证失败，白名单更新失败。
本申请实施例中，可以对发布白名单进行有效性验证，通过验证远程设备标识与授权令牌中的被控制对象标识的一致性、验证白名单验证白名单签发时间是否小于或等于第一阈值以及验证白名单签名的一致性的方式保证白名单不被攻击，可以降低用户的隐私泄露和财产损失的风险。此外，验证白名单有效性的方案也可以替换成为验证黑名单有效性的方案。
一种可能的实现方式中，在步骤S505中，还包括：对白名单特征值进行签名和/或加密；所述远程设备向终端设备发送经过签名和/或加密后的白名单特征值，用于终端设备确认签发的白名单与远程设备接收到的白名单的一致性。
具体地，远程设备可以根据白名单计算出白名单特征值，并通过签名密钥或加密的方式对特征值进行签名或加密。其中，签名密钥既可以采用对称密钥或者远程设备的私钥。得到签名或加密的特征值之后，远程设备可以向终端设备发送该经过签名或加密的白名单特征值，终端设备验证接收的特征值与发送的白名单特征值一致性，若通过验证，保存该白名单特征值作为后续验证从设备管理***获取的白名单有效性使用。
本申请实施例中，提出了白名单的特征值机制，远程设备从白名单中可以获取白名单的特征值。由于白名单的特征值中记载了白名单的关键信息或指纹信息，可以起到代替白名单的作用，并且白名单特征值占用设备的空间小，可以降低手机等设备的存储开销。此外，远程设备可以通过对白名单特征值签名和/或加密的方式，进一步保障白名单特征值的使用安全。此外，白名单特征值方案，也可以替换为黑名单特征值方案。
下面结合图6至图16所示的过程对本申请的实施例进行详细说明。
图6是本申请实施例提供的一种授权令牌签发和鉴权流程图600。图6中的方法可应用于图1的远程控制***100中。该方法可以包括如下步骤。
S601，用户通过终端远控APP对远程设备进行监控、查看和操作。
S602，生成授权令牌内容。
如图7所示，***根据用户在终端远控APP的操作自动生成授权令牌700中的授权令牌内容710(TOKEN_CONTENT)。
授权令牌内容710可以包括：令牌ID 711(TOKEN_ID)、签发者标识712(ISSUER_ID)、被授权对象标识713(AUTHORIZED_OBJ_ID)、授权内容列表714(可以多组)、被控制标识715(OBJECT_ID)、操作716(OPERATE)、关键参数717(KEY_PARAMETER)、签发时间718(ISSUE_TIME)、有效期开始时间719(VALIDITY_START_TIME)和有效期结束时间720(VALIDITY_EXIRATION_TIME)。
其中，远程设备可以根据签发者标识712加载令牌的签名密钥，被授权对象标识713可以为设备管理***的ID，被控制标识715可以为远程设备ID，操作716可以指远程控制的一个操作或具有相同安全等级的一类操作，关键参数717可以指远程控制涉及到用户生命和财产安全等核心利益的参数。
应理解，关键参数717可以是一个具体的数值，也可以是一个参数的取值范围，本申请实施例对此不做限定。当关键参数717是一个取值范围时，设备管理***可以在其取值范围内调整参数。
有效期开始时间719可以用下列公式表示：
令牌有效期开始时间＝***当前时间–时间同步偏差(TIME_SYN_ERROR)
有效期结束时间720可以用下列公式表示：
令牌有效期开始时间＝***当前时间+操作预留时间(OPERATE_RESERVE_TIME)+时间同步偏差(TIME_SYN_ERROR)
应理解，操作预留时间(OPERATE_RESERVE_TIME)可以根据操作的复杂度进行预设，时间同步偏差(TIME_SYS_ERROR)是指根据***内多个设备间可容忍的时间同步偏差。本申请实施例对操作预留时间和时间同步偏差的具体数值不做限定。
S603，生成授权令牌数字签名。
如图7所示，***根据用户在终端远控APP的操作自动生成授权令牌700中的授权令牌签名730(TOKEN_SIGNATURE)。
其中，授权令牌签名730的生成方式可以用以下公式进行表示：
授权令牌签名730＝签名算法731|签名数据732(SIGNATURE_DATA)。
其中，生成签名数据732可以采用基于对称密钥的消息认证码MAC算法或基于非对称密钥的数字签名算法。
S604，生成授权令牌。
具体地，授权令牌可以由授权令牌内容710和授权令牌签名730组合而成。可以通过以下公式表示。
AUTHRIZATION_TOKEN＝TOKEN_CONTENT|TOKEN_SIGNATURE。
应理解，本申请实施例中生成授权令牌的方式仅是示例性说明，生成授权令牌也可以采用其他的方式。例如，授权令牌可以仅由授权令牌内容710中的部分内容组成，又例如，授权令牌签名730可以仅包含签名数据732。又例如，授权令牌可以附加二次令牌签名等额外的加密措施，本申请实施例对生成授权令牌的方式不作限定。
本申请实施例中，可以根据用户操作自动生成授权令牌，按需签发令牌，保证授权范围的最小化，降低用户的隐私泄露和财产损失的风险。生成的授权令牌可以根据实际的需求灵活调整授权令牌内容，以适应不同的授权令牌应用场景，此外，可以对生成的授权令牌进行签名和/或加密的方式保障授权令牌的使用安全。
S605，终端远控APP向设备管理***发送第一请求信息。
一种可能的实现方式中，第一请求信息中包括操作请求和授权令牌。
S606，设备管理***进行业务处理。
具体地，设备管理***对接收到的用户的不同操作请求进行处理，生成对应的远控指令，并将操作指令发送给远程设备，进而实现用户的远程控制。
S607，设备管理***向远程设备发送第二请求信息。
一种可能的实现方式中，第二请求信息中包括远控指令和授权令牌。
本申请实施例中，通过授权令牌方式，可以使终端远控APP与设备管理***间的通信协议，以及设备管理***与远程设备间的通信协议解耦。并且，设备管理***在远程控制算法中有比较充分自由度，可以在授权范围内下发远控最优参数，实现良好的远程控制效果。
S608，远程设备对令牌的有效性进行验证。
S609，远控指令合法性验证。
S610，执行远控指令。
具体地，在授权令牌的有效性和远控指令的合法性验证通过后，远程设备执行用户的远控指令。
基于此，用户实现了对远程设备的远程控制。
S611，记录日志。
具体地，远程设备对执行远控指令情况进行记录。远程设备的拥有者或管理者可以通过日志来查看远控指令的执行过程和执行结果。
其中,如果远控指令执行失败，远程设备的拥有者或管理者可以通过日志的记录，了解任务执行失败的原因，或者远程设备也可以通过其他的方式向设备的拥有者或管理者反馈信息，设备的拥有者或管理者可以通过远程设备反馈的信息及时了解任务执行失败的原因，进而采取一定改进措施，以确保下一次远程控制任务能够被成功执行。
本申请实施例中，通过终端远控APP签发授权令牌的方式，向远程设备传递指示信息，远程设备可以对令牌和远控指令进行验证，以保证远控指令与设备拥有者/被授权者意图一致，降低用户的隐私泄露和财产损失风险。
图8是本申请实施例提供的一种授权令牌有效性验证流程图800，该方法800可应用于图6中的授权令牌有效性验证，如图8所示，方法800可包括如下步骤。
S801，验证设备管理***与被授权对象标识是否一致。
具体地，验证下发的远控指令的设备管理***与被授权对象标识(AUTHORIZED_OBJ_ID)的一致性，如果一致则进行步骤S802。如果验证失败，则远程控制流程结束。
S802，验证被控制对象ID与远程设备标识是否一致，若一致，则进行步骤S803，若不一致，远控流程结束。
S803，验证令牌的时间有效性。
具体地，验证令牌时间的有效性可以通过判断***当前时间是否满足预设范围来确定。
例如，可以通过设置***当前时间小于或等于令牌有效期结束时间720时，时间有效性验证通过。否则验证失败，远控流程结束。
又例如，可以通过设置***当前时间大于或等于令牌有效期开始时间719，且小于或等于令牌有效期结束时间720时，时间有效性验证通过。否则验证失败，远控流程结束。
S804，验证令牌签发者的验签密钥是否已经在远程设备端配置。
具体地，可以通过签发者标识721和签名算法731获取提前分发的远程设备验签密钥，如果验签密钥已经配置，则进行步骤S804，如果验证失败，则远控流程结束。
S805，验证授权令牌数字签名是否一致。
具体地，可以通过如下步骤进行验证。
输入：授权令牌、远程设备验签密钥
输出：签名是否有效
处理过程：
(1)从授权令牌中获取授权令牌内容710、签名算法731、签名数据732。
(2)根据签名算法731和远程设备验签密钥，对授权令牌进行签名验证。如果授权令牌签名一致，则验证通过；否则，签名验证失败，远控流程结束。
图9是本申请实施例提供的一种远控指令合法性验证流程图900，方法900可应用于图6的远控指令的合法性验证，如图9所示，方法900可包括如下步骤。
S901，验证远程设备标识与授权令牌中的被控制对象标识是否一致。
具体地，验证远控指令中设备对象ID与授权令牌中的被控制对象标识713是否一致，如果一致则进行步骤S902，如果不一致，则远控流程结束。
S902，验证远控指令是否在授权令牌的允许操作范围内。
具体地，验证远控指令中操作指令与授权令牌中的操作716是否一致或是否属于操作716列表的范围内。如果一致或在其列表范围内，则进行步骤S903，如果不一致或不在其列表范围内，则远控流程结束。
S903，验证关键参数是否在授权令牌的关键参数范围内。
具体地，验证远控指令中关键参数是否在授权令牌关键参数717的允许范围内，如果在其允许范围内，则通过远控指令的合法性验证。如果不在其允许的范围内，则远控流程结束。
上述实施例给出了在即时交互场景下的授权令牌实施方案。在远程控制应用中，另一种常见的应用场景是周期性控制、预约控制、授权管理，如定时备车功能，预约备车功能，委托远程诊断等功能。在这些场景下，用户处于离线状态，由设备管理***代替用户发起远程设备的控制。用户无法即时签发授权令牌，需要提前签发授权令牌并保存在设备管理***，授权令牌的有效期会有比较长时间。相对于即时交互场景下的授权令牌方案，不仅需要考虑因密钥变更，授权令牌的重新签署的情况；还需要考虑用户计划变更，授权令牌的重新签署和吊销等情况。
基于此，为支持授权令牌的更新、吊销流程，在下面的实施例中，在授权令牌的基础上，通过引入长期授权令牌白名单方案，只有在白名单方案中的长期授权令牌，才是有效的。
图10是本申请实施例提供的另一种远程控制***1000，该远程控制***可以支持长期授权令牌的远程控制方案。
如图10所示，用户1001可以是远程设备1005的拥有者或被授权者，被允许通过终端远控APP 1002控制远程设备1005。终端远控APP 1002可以安装在手机等终端设备上，用户1001可以通过终端远控APP 1002远程查看、操作、管理远程设备1005。
设备管理***1003可以部署在云上或服务器上，能支持终端远控APP 1002和远程设备1005的接入，并为他们提供服务。
密钥管理***1004负责给终端远控APP 1002和远程设备1005分发密钥。其可以是独立的***，也可以集成到设备管理***1003中。其可以部署在云上，也可以部署在专用服务器上，本申请实施例对此不作限定。
远程设备1005为设备所有人所有，其可以是智能汽车，智能家居等等，设备拥有人或授权人员可以在近端操作该远程设备1005，也可以通过终端远控APP 1002远程操作该远程设备1005。远程设备1005可以直接由设备拥有人或授权人员直接管理。
时间同步***1006可以为终端1002、设备管理***1003和远程设备1005提供时间同步，以保证远程控制***1000运行良好。其中，时间同步可以通过GNSS进行，也可以通过其他方式进行，本申请实施例对此不作限定。
通信链路1007可以是终端远控APP 1002与设备管理***1003之间的通信链路。通过该链路，终端远控APP 1002进入设备管理***1003对远程设备1005进行远程控制。设备管理***1003可以对终端远控APP 1002进行认证和鉴权，使两者间建立安全传输通道，例如HTTPS等，以保证通信安全。
通信链路1008可以是远程设备1005接入到设备管理***1003的通信链路。设备管理***1003可以通过该线路管理和控制远程设备1005。远程设备1005与设备管理***间进行认证和鉴权，建立安全传输通道，例如DTLS等，以保证通信安全。
用户签名密钥1009可以由密钥管理***1004分配，授权令牌签名可以采用对称密钥的消息认证码MAC或非对称密钥的数字签名算法等等。当授权令牌签名采用基于对称密钥的消息认证码MAC时，用户签名密钥1009与远程设备验签密钥1010相同，当授权令牌签名采用基于非对称密钥的数字签名算法时，保存用户1001的私钥，用于授权令牌签名和长期授权令牌白名单签名；同时保存远程设备1005的公钥，用于与远程设备通信。
远程设备验签密钥1010可以由密钥管理***1004分配，授权令牌签名可以采用对称密钥的消息认证码MAC或非对称密钥的数字签名算法等等。当授权令牌签名采用基于对称密钥的消息认证码MAC时，用户签名密钥1009与远程设备验签密钥1010相同，当授权令牌签名采用基于非对称密钥的数字签名算法时，终端远控APP 1002保存用户1001的私钥，用于签发授权令牌签名和长期授权令牌白名单签名；同时保存远程设备1005的公钥，用于验证远程设备返回的长期授权令牌白名单特征值的签名。同时在远程设备端保存用户1001的公钥，用于对授权令牌和长期授权令牌白名单的签名验证；并保存远程设备1005的私钥，用于在白名单发布过程中的白名单特征值进行签名。
授权令牌1011在终端远控APP 1002签发有效期长的授权令牌后，在设备管理***1003侧存储，以供后续远控业务使用。
长期任务授权令牌白名单1012是长有效期的授权令牌ID的列表，用户密钥对其进行签名保护。长期任务授权令牌白名单签发后保存在设备管理***1003和远程设备1005中。
长期任务授权令牌白名单特征值1013是全局区分白名单的一个标识，可以从白名单计算得到的唯一能标识白名单的信息，可以由白名单中的字段、签发者标识、白名单ID、签发时间、指纹信息等项目组合成为白名单特征值1013。白名单特征值1013由白名单生成，可以确保设备管理***1003保存的白名单、下发到远程设备1005的白名单和终端签发的白名单保持一致，保证白名单发布和保存过程的安全性。
图11是本申请实施例提供的一种长期任务授权令牌白名单结构1100。图11的长期任务授权白名单可应用于图10的远程控制***1000中。
长期任务授权白名单可以包括白名单内容1110和白名单签名1120。
其中，白名单内容1110可以包括：白名单ID 1111、签发者标识1112、被授权对象标识1113、被控制对象1114、授权令牌ID列表1115、签发时间1116。白名单签名1120可以包括签名算法1221和签名数据1122。
其中，白名单ID 1111可以指由该用户签发的白名单唯一标识，签发者标识1112可以指白名单签发者ID，授权令牌ID列表1115可以指由该用户签发的未被撤销的授权令牌列表，签发时间1116可以指白名单签发时间。签名算法1221可以指白名单的签名算法，例如采用HMAC，RSA等算法。签名数据1222可以指由用户的密钥对白名单内容进行数字签名(或消息认证码)结果。
应理解，本申请实施例中，对长期授权令牌白名单内容和签名的举例仅是示例性的说明，长期授权令牌白名单内容和签名中的项目可以根据实际的需要进行调整，以适应不同的白名单应用场景，例如，白名单可以包括白名单所有内容中的部分内容，又例如，可以对白名单的签名数据进行加密，以保证白名单的使用安全。
本申请实施例中，为了支持授权令牌的作废和撤销，采用了签署长期任务授权令牌白名单的方案。通过限定白名单中的授权令牌才是有效的，支持了周期性控制、预约控制、授权管理等等场景下的远程控制方案。
图12是本申请实施例提供的一种长期任务授权令牌白名单签发流程图1200，方法1200可应用于图10的远程控制***1000中。方法1200可以包括如下步骤。
S1201，终端远控APP向设备管理***发送获取长期授权令牌白名单请求信息。
S1202，设备管理***返回白名单，终端远控APP获取长期授权令牌白名单。
应理解，长期授权白名单可以保存在设备管理***中，也可以保存在终端设备中，还可以保存在其他位置，本申请实施例此不做限定。
S1203，终端远控APP对白名单的有效性进行验证。
S1204，根据用户操作的任务类型，确定是否签发新授权令牌和是否更新白名单。
具体地，当用户的操作指令涉及增加新的长期任务时，需要签发新的令牌，并在白名单中更新令牌的ID。
当用户的操作指令涉及长期任务变更，并且该任务变更不涉及令牌内容调整时。需要根据原来的白名单和授权令牌执行用户变更操作命令。
当用户的操作指令涉及长期任务变更，并且该任务变更涉及令牌内容调整时，需要签发新的令牌。此时，在白名单中需要删除老授权令牌的ID，增加新授权令牌的ID。
应理解，本申请实施例根据用户操作的任务类型，确定是否签发新授权令牌和是否更新白名单的方法仅是示例性的说明，本申请实施例对此不做限定。
S1205，如果在步骤S1204中确定需要签发新授权令牌，则在此步骤中签发新授权令牌，如果在步骤S1204中确定不需要签发新授权令牌，则跳过此步骤。
S1206，如果在步骤S1204中确定需要更新白名单，则在此步骤中更新白名单，如果在步骤S1204中确定不需要更新白名单，则跳过此步骤。
S1207，终端运控APP向设备管理***发送第一请求信息。
可选地，第一请求信息中包括：任务请求、授权令牌和长期授权令牌白名单。
本申请实施例中，为支持授权令牌的作废和撤销，通过在第一请求信息中部署白名单的方式，支持了周期性控制、预约控制、授权管理等场景下的远程控制方案。保障了授权令牌的使用安全。
S1208，设备管理***进行业务处理。
具体地，该步骤中设备管理***对接收到的用户的不同操作请求进行处理，生成对应的远控指令，并将操作指令发送给远程设备，进而实现用户的远程控制。
S1209，设备管理***保存授权令牌和长期授权令牌白名单。
具体地，设备管理***可以保存授权令牌和长期授权令牌白名单，供后续业务使用。
S1210，设备管理***将长期授权令牌白名单发送到远程设备，使远程设备更新白名 单。
S1211，远程设备接收到长期授权令牌白名单后，对白名单的有效性进行验证，验证通过，更新远程设备侧的白名单；否则白名单更新失败。
S1212，远程设备进行白名单特征值签名。
白名单的特征值中记载了白名单的关键信息或指纹信息，在某些场景下可以起到代替白名单的作用，并且白名单特征值占用设备的空间小，可以降低手机等设备的存储开销。
具体地，远程设备可以从获取的白名单中计算得到特征值，并通过远程设备的签名密钥对特征值进行签名。其中，获取白名单特征值可以采用不同的方式，例如，可以通过一些算法或函数从白名单中摘要一些关键信息(关键字段、字节等)来获取白名单的特征值，具体地，可以通过Hash函数对白名单中的关键信息进行处理，生成Hash函数值，并将Hash函数值作为白名单特征值使用。又例如，可以将白名单ID作为白名单特征值进行使用。
其中，远程设备的签名密钥对特征值进行签名时，使用的签名密钥既可以采用对称密钥或者远程设备的私钥。签名也可替换为远程设备对白名特征值进行加密处理，加密处理和进行签名都是为了提高白名单特征值的使用安全性。
S1213，远程设备向终端远控APP返回白名单特征值及其签名。
具体地，远程设备可以向终端设备发送该经过签名的白名单特征值，使终端设备验证并保存该白名单特征值。
如果在步骤S1212中，对白名单特征值进行加密处理，则此步骤为远程设备向终端远控APP返回经过加密的白名单特征值。
S1214，终端远控APP用对称密钥或远程设备的公钥对白名单特征值二次签名验证。
具体地，终端远控APP可以使用对称密钥或远程设备的公钥对经过签名的白名单特征值进行二次签名认证，如果通过该签名认证，则保存白名单特征值及其新签名，如果认证不通过，则舍弃或撤销该白名单特征值。通过此种方式，可以保证从外部获取白名单的有效性，防止白名单被非法替换。
白名单特征值的二次签名验证过程包括：1)用对称密钥或远程设备的公钥对白名单特征值签名进行验证，验证通过进入下一步；2)对S1207第一请求信息中发送的白名单生成白名单特征值；并与S1213返回的特征值进行比较，如果一致，则白名单签发成功；否则白名单被非法篡改，需要触发白名单撤销过程。
如果在S1213中终端远控APP接收的是经过加密处理的白名单特征值，则此步骤为对经过加密的白名单进行二次认证。
S1215，保存白名单特征值，用于下一次验证从设备管理***获取的白名单完整性使用。
具体地，终端远控APP对最新白名单特征值进行签名或加密，本地保存白名单特征值及其签名。
本申请实施例中，在签署授权令牌的同时发布白名单，并通过验证白名单有效性，保证白名单不被攻击，可以降低用户的隐私泄露和财产损失的风险。此外，并且本申请实 施例可以通过本地保存的白名单特征值机制，保证了从外部获取白名单的有效性，防止白名单被非法替换，并通过特征值机制降低手机等设备的存储开销。
其中，白名单方案也可以替换为黑名单方案，可以对黑名单进行有效性验证，特征值验证等等。
图13是本申请实施例提供的一种终端设备的白名单有效性验证流程图1300，方法1300可应用于图12中的终端设备对白名单的有效性验证过程的步骤S1203中。如图13所示，方法1300可以包括如下步骤。
S1301，验证白名单签发者是否有效。
具体的，检查从设备管理***获取的白名单中的签发者标识1112与终端远控APP身份标识一致，若一致则进行步骤S1302，若不一致则白名单无效，验证失败。
S1302，验证白名单被授权对象是否有效。
具体地，检查从设备管理***获取的白名单中的被授权对象标识1113与当前登录的设备管理***ID一致，若一致则进行步骤S1303，若不一致则白名单无效，验证失败。
S1303，验证白名单控制对象是否有效。
具体地，检查从设备管理***获取的白名单中的被控制对象标识1113与操作的远程设备ID一致，若一致则进行步骤S1304，若不一致，则白名单无效，验证失败。
S1304，验证白名单特征值的一致性。
具体的，验证终端设备验证已经保存的与获取到的白名单计算得到的特征值的一致性。如果验证白名单特征值一致，则进行步骤S1305，如果验证白名单特征值不一致，则白名单无效，验证失败。为了保证已经保存白名单不被篡改，可以通过签名或加密的方式对白名单特征值进行保护。
S1305，验证白名单签名是否一致。
具体地，对用户自己签发的白名单进行有效性验证。如果验证通过，则通过白名单有效性进行验证。如果签名有效性验证不通过，则白名单无效，白名单有效性验证失败。
图14是本申请实施例提供的一种远程设备的白名单更新有效性验证流程图1400。该方法可应用于图12中步骤S1211/S1212白名单有效性的验证过程中，方法1400可以包括如下步骤。
S1401，验证白名单中的被控制对象与远程设备标识是否一致。
具体地，比较白名单中的被控制对象与远程设备标识，如果一致则进行步骤S1402，如果不一致，则白名单更新有效性验证失败。
S1402，验证白名单签发时间的是否小于等于第一阈值。
具体地，验证白名单签发时间是否小于或等于第一阈值可以指判断白名单的签发时间是否在远程设备***当前时间差允许的范围内。
S1403，验证白名单签名的一致性。
具体地，验证白名单签名的一致性可以指利用密钥对白名单签名的有效性进行验证，如果白名单的签名和密钥一致，则签名验证成功，白名单更新成功；如果白名单签名和密钥不一致，则签名验证失败，白名单更新失败。
在签署长期任务授权令牌白名单的方案中，由于终端远控APP可能需要对密钥进行 更新，以保证用户的使用授权令牌的安全。在此种情况下，需要对已经签发的长期授权令牌和长期授权令牌白名单进行重新签发。
图15是本申请实施例提供的一种授权令牌重新签发流程图1500，方法1500可应用于图10的远程控制***1000中。方法1500可以包括如下步骤。
S1501，终端远控APP进行密钥更新，同时，密钥管理***需要在终端远控APP和远程设备同时更新最新的密钥。
S1502，终端远控APP从设备管理***中获取长期授权令牌和白名单。
S1503，终端远控APP用更新前的密钥对获取到的白名单有效性进行验证，白名单有效性验证包括满足以下两个条件：
白名单签名一致性；
基于从设备管理***获得的白名单计算出白名单特征值，该特征值与终端远控APP保存的特征值一致。
S1504，终端远控APP用更新前的密钥对授权令牌有效性进行验证，并且坚持授权令牌ID在白名单的授权令牌ID列表中。如有效性验证通过，则进行步骤S1505，如果有效性验证不通过，则过程终止，长期任务需要重新创建。
S1505，终端远控APP用更新后的密钥对长期授权令牌白名单进行重新签发。
S1506，终端远控APP用更新后密钥对长期授权令牌进行重新签发。
S1507，终端远控APP向设备管理***发送第三请求信息。
一种可能的实现方式中，第三请求信息中包括长期授权令牌和长期授权令牌白名单。
S1508，设备管理***保存授权令牌和长期授权令牌白名单。
具体地，设备管理***可以保存授权令牌和长期授权令牌白名单，供后续业务使用。
S1509，设备管理将长期授权令牌白名单发送到远程设备，使远程设备更新白名单。
S1510，远程设备接收到长期授权令牌白名单后，更新白名单，并对更新后的白名单的有效性进行验证。
具体地，验证所述白名单的有效性包括以下内容至少一项：验证白名单被控对象与远程设备标识的一致性、验证白名单签发时间是否小于或等于第一阈值、验证白名单签名的一致性。
S1511，远程设备进行白名单特征值签名。
具体地，远程设备可以获取的白名单中计算得到特征值，并通过签名密钥对特征值进行签名。其中，签名密钥既可以采用对称密钥或者远程设备的私钥。
S1512，远程设备向终端远控APP返回白名单特征值签名。
具体地，远程设备可以向终端设备发送该经过签名的白名单特征值，使终端设备验证并保存该白名单特征值。
S1513，终端远控APP对白名单二次签名验证。
具体地，终端远控APP可以对经过签名的白名单特征值进行二次签名认证，如果通过该签名认证，则保存白名单特征值及其新签名，如果认证不通过，则舍弃该白名单特征值。通过此种方式，可以保证从外部获取白名单的有效性，防止白名单被非法替换
白名单特征值的二次签名验证过程包括：1)用对称密钥或远程设备的公钥对白名单 特征值签名进行验证，验证通过进入下一步；2)对S1507第一请求信息中发送的白名单生成白名单特征值；并与S1512返回的特征值进行比较，如果一致白名单签发成功；否则白名单被非法篡改，需要触发白名单撤销过程。
S1514，保存白名单特征值。
具体地，终端远控APP对最新白名单特征值进行签名，本地保存白名单特征值及其签名。
本申请实施例中，在密钥需要更新的场景下，通过新密钥对授权令牌和白名单进行重新签发方式，保证了授权令牌和白名单的安全使用。此外，也可以通过新密钥对授权令牌和黑名单进行重新签发方式，保证授权令牌和黑名单的安全使用。
图16是本申请实施例提供的一种长期授权令牌有效性验证流程图1600，图16在原先图8的基础上增加了步骤S1604，即验证授权令牌ID是否在长期授权令牌ID列表中。方法1600执行的具体步骤如下。
S1601，验证设备管理***与被授权对象标识是否一致。
具体地，验证下发的远控指令的设备管理***与被授权对象标识(AUTHORIZED_OBJ_ID)的一致性，如果一致则进行步骤S1602。如果验证失败，则远程控制流程结束。
S1602，验证被控制对象ID与远程设备标识是否一致。
具体的，若被控制对象ID与远程设备标识一致，则进行步骤S1602，若不一致，则验证失败，远程控制流程结束。
S1603，验证令牌的时间有效性。
可选地，验证令牌时间的有效性可以通过判断***当前时间是否满足预设范围来确定。
例如，可以通过设置***当前时间小于或等于令牌有效期结束时间720时，时间有效性验证通过。否则验证失败，远控流程结束。
又例如，可以通过设置***当前时间大于或等于令牌有效期开始时间719，且小于或等于令牌有效期结束时间720时，时间有效性验证通过。否则验证失败，远控流程结束。
S1604，检查授权令牌ID是否在长期授权令牌白名单1000的授权令牌ID列表1115中，如果在该列表中，则进行步骤S1605，如果不在列表中，则验证失败。
S1605，验证令牌签发者的验签密钥是否已经在远程设备端配置。
具体地，可以通过签发者标识721和签名算法731获取提前分发的远程设备验签密钥，如果远程验签密钥已经配置，则进行步骤S1606，如果验证失败，则远控流程结束。
S1606，验证授权令牌数字签名是否一致。
具体地，可以通过如下步骤进行验证。
输入：授权令牌、远程设备验签密钥
输出：签名是否有效
处理过程：
(1)从授权令牌中获取授权令牌内容710、签名算法731、签名数据732。
(2)根据签名算法731和远程设备验签密钥，对授权令牌进行签名验证。如果授权 令牌签名一致，则验证通过；否则，签名验证失败，远控流程结束。
上述实施例给出了在远程控制应用中，为了支持授权令牌的作废和撤销，采用了签署长期任务授权令牌白名单的方案。通过限定白名单中的授权令牌才是有效的，支持了周期性控制、预约控制、授权管理等等场景下的远程控制方案。
其中，白名单方案也可以替换成黑名单方案，用长期授权令牌黑名单替代长期授权令牌白名单，将已经吊销的令牌保存到黑名单。在远程设备进行授权令牌有效性验证中，如果授权令牌ID在黑名单中，则授权令牌为非法，验证不通过。为避免黑名单变得越来越长，可以将已经过期的授权令牌从黑名单中剔除，精简黑名单长度。
应理解，本文中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本申请的保护范围中。例如，远程控制令牌方法可以单独使用，也可以和长期授权令牌白名单方法结合使用。又如，长期授权令牌黑名单方法可以单独使用，也可以和长期授权令牌白名单方法结合使用，等等。
图17是本申请实施例提供的一种远程控制装置1700。该装置可应用于图1中的远程控制***100中，也可应用于图10的远程控制***1000中。
该装置1700可以包括收发单元1710、获取单元1720和处理单元1730。收发单元1710可以实现相应的通信功能，收发单元1710还可以称为通信接口或通信单元。获取单元1720可以用于获取相应的指令和/或数据，处理单元1730用于进行数据处理。处理单元1730可以读取存储单元中的指令和/或数据，以使得装置实现前述方法实施例。
可选地，该装置2000还可以包括存储单元，该存储单元可以用于存储指令和/或数据。
作为一种设计，该装置1700用于执行上文方法实施例中终端设备或终端远控APP所执行的动作。
一种可能的实现方式中，该装置1700包括：获取单元1720和收发单元1710；获取单元1720：用于获取授权令牌，所述授权令牌包括授权令牌内容和授权令牌签名信息；收发单元1710：用于向设备管理***发送的第一请求信息，所述第一请求信息包括操作请求和授权令牌。所述操作请求用于请求所述设备管理***向远程设备下发远控指令，所述授权令牌用于配合所述远控指令的合法性验证。
可选地，所述授权令牌内容包括：令牌ID、签发者标识、被授权对象标识、授权内容列表、签发时间、有效期开始时间、有效期结束时间中的至少一项。所述授权内容列表包括：被控制对象标识、操作、关键参数中的至少一项；所述授权令牌签名信息包括：签名数据或，签名数据和签名算法。
一种可能的实现方式中，所述第一请求信息还包括：白名单，所述白名单包括：白名单内容和白名单签名信息；所述白名单内容包括：白名单ID、签发者标识、被授权对象标识、被控制对象、授权令牌ID列表、签发时间中的至少一项；所述白名单签名信息包括：签名数据或，签名数据和签名算法。
一种可能的实现方式中，获取单元1720还用于：获取白名单；该装置还包括处理单元1730，用于所述白名单的有效性；所述处理单元1730具体用于验证以下内容至少一项：验证白名单签发者是否有效、验证白名单被授权对象是否有效、验证白名单控制 对象是否有效、验证白名单签名是否一致。
一种可能的实现方式中，该装置还包括存储单元，用于保存白名单特征值；处理单元1730还用于：使用所述白名单特征值，验证所述白名单的有效性。
一种可能的实现方式中，获取单元1720还用于：获取白名单特征值，处理单元1730具体用于：对所述白名单特征值进行验证，若通过所述验证，所述存储单元用于保存所述白名单特征值。
一种可能的实现方式中，所述白名单特征值为经过签名和/或加密的白名单特征值。
一种可能的实现方式中，所述处理单元还用于对白名单特征值进行验签和/或解密。
一种可能的实现方式中，该装置中的处理单元还用于1730：生成授权令牌内容，并签发所述授权令牌；确定用户操作的任务类型；根据所述用户操作的任务类型，确定是否签发新授权令牌和是否更新所述白名单。
一种可能的实现方式中，该装置中的处理单元1730还用于更新密钥；用更新后的密钥重新签发白名单和授权令牌；收发单元1710还用于向设备管理***发送第三请求信息，所述第三请求信息包括所述重新签发的白名单和授权令牌。
作为一种设计，该装置1700用于执行上文方法实施例中设备管理***所执行的动作。
一种可能的实现方式中，该装置包括收发单元1710和处理单元1730；所述收发单元用于1710：接收第一请求信息，所述第一请求信息包括操作请求和授权令牌；所述处理单元1730用于：根据所述操作请求，生成远控指令，所述远控指令用于指示远程设备执行所述操作请求。
一种可能的实现方式中，收发单元1710还用于：向远程设备发送第二请求信息，所述第二请求信息包括所述远控指令和授权令牌，所述授权令牌用于配合所述远控指令的合法性验证。
一种可能的实现方式中，该装置包括还存储单元，该存储单元用于：保存所述授权令牌和白名单；处理单元1730还用于更新所述白名单，收发单元1710还用于向远程设备发送更新后的白名单。
作为一种设计，该装置1700用于执行上文方法实施例中远程设备所执行的动作。
一种可能的实现方式中，该装置包括收发单元1710和处理单元1730；所述收发单元1710用于：接收第二请求信息，所述第二请求信息包括远控指令和授权令牌；所述处理单元1730用于：验证所述授权令牌的有效性，若所述授权令牌有效，则验证所述远控指令的合法性。
可选地，验证授权令牌的有效性包括以下内容至少一项：验证设备管理***与被授权对象标识是否一致、验证被控制对象ID与远程设备标识是否一致、验证令牌的时间有效性、验证令牌签发者的验签密钥是否已经在远程设备端配置、验证授权令牌数字签名是否一致。
可选地，验证远程指令的合法性包括以下内容至少一项：验证远程设备标识与授权令牌中的被控制对象标识是否一致、验证远控指令是否在授权令牌的允许操作范围内、验证关键参数是否在授权令牌的关键参数范围内。
一种可能的实现方式中，所述第二请求信息中包括白名单，处理单元1730具体用于： 验证授权令牌ID是否在白名单ID列表中。
一种可能的实现方式中，所述第二请求信息中包括黑名单，所述处理单元1730具体用于：验证授权令牌ID是否在黑名单ID列表中。
一种可能的实现方式中，所述处理单元1730还用于：验证所述白名单的有效性。所述处理单元1730具体用于：验证远程设备标识与白名单中被控制对象标识的一致性、验证白名单签发时间是否小于或等于第一阈值、验证白名单签名的一致性。
一种可能的实现方式中，所述处理单元1730还用于：根据所述白名单确定白名单特征值，所述白名单特征值用于标识所述白名单。所述处理单元1730还用于对所述白名单特征值进行签名和/或加密；所述收发单元1710用于向终端设备发送经过签名和/或加密后的白名单特征值。
应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。
还应理解，图17中的处理单元可以由至少一个处理器或处理器相关电路实现，获取单元和收发单元可以由收发器或收发器相关电路实现，存储单元可以通过至少一个存储器实现。
图18是本申请实施例提供的一种远程控制装置1800示意图。该装置可应用于图1的远程控制***100中，也可应用于图10的远程控制***1000中。
该远程控制装置包括：存储器1810、处理器1820、以及通信接口1830。其中，存储器1810、处理器1820，通信接口1830通过内部连接通路相连，该存储器1810用于存储指令，该处理器1820用于执行该存储器1820存储的指令，以控制输入/输出接口1830接收/发送第二信道模型的至少部分参数。可选地，存储器1810既可以和处理器1820通过接口耦合，也可以和处理器1820集成在一起。
需要说明的是，上述通信接口1830使用例如但不限于收发器一类的收发装置，来实现通信设备1800与其他设备或通信网络之间的通信。上述通信接口1830还可以包括输入/输出接口(input/output interface)。
在实现过程中，上述方法的各步骤可以通过处理器1820中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1810，处理器1820读取存储器1810中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
本申请实施例还提供一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得所述计算机执行上述图3至图16中的任一种方法。
本申请实施例还提供一种芯片，包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行上述图3至图16中的任一种方法。
本申请实施例还提供一种车辆，包括：至少一个处理器和存储器，所述至少一个处理 器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行上述图3至图16中的任一种方法。
本申请实施例还提供一种智能车辆，包括图17或图18任一种远程控制授权令牌装置。
应理解，本申请实施例中，上述处理器可以为中央控制单元(central processing unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
还应理解，本申请实施例中，该存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。处理器的一部分还可以包括非易失性随机存取存储器。例如，处理器还可以存储设备类型的信息。
应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
还应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
在本说明书中使用的术语“部件”、“模块”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示，在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中，部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外，这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地***、分布式***和/或网络间的另一部件交互的二个部件的数据，例如通过信号与其它***交互的互联网)的信号通过本地和/或远程进程来通信。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的***、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或 组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (26)

  1. 一种远程控制的方法，其特征在于，包括：
    远程设备从设备管理***接收第二请求信息，所述第二请求信息包括远控指令和授权令牌；
    所述远程设备验证所述授权令牌的有效性；
    所述远程设备在所述授权令牌有效的情况下，使用所述授权令牌验证所述远控指令的合法性。
  2. 如权利要求1所述的方法，其特征在于，所述授权令牌包括授权令牌内容和授权令牌签名信息；
    所述授权令牌内容包括：令牌ID、签发者标识、被授权对象标识、授权内容列表、签发时间、有效期开始时间、有效期结束时间中的至少一项；
    所述授权内容列表包括：被控制对象标识、操作、关键参数中的至少一项；
    所述授权令牌签名信息包括签名数据，或
    所述授权令牌签名信息包括签名数据和签名算法。
  3. 如权利要求1或2所述的方法，其特征在于，所述验证所述授权令牌的有效性包括以下内容至少一项：
    验证设备管理***与被授权对象标识是否一致、验证被控制对象ID与远程设备标识是否一致、验证令牌的时间有效性、验证令牌签发者的验签密钥是否已经在远程设备端配置、验证授权令牌数字签名是否一致。
  4. 如权利要求1至3任一项所述的方法，其特征在于，所述使用所述授权令牌验证远程指令的合法性包括以下内容至少一项：
    验证远程设备标识与授权令牌中的被控制对象标识是否一致、验证远控指令是否在授权令牌的允许操作范围内、验证关键参数是否在授权令牌的关键参数范围内。
  5. 如权利要求1至4任一项所述的方法，其特征在于，所述第二请求信息中还包括黑名单，所述验证授权令牌的有效性还包括：验证授权令牌ID是否在黑名单ID列表中。
  6. 如权利要求1至4任一项所述的方法，其特征在于，所述第二请求信息中还包括白名单，所述验证授权令牌的有效性还包括：验证授权令牌ID是否在白名单ID列表中。
  7. 如权利要求6所述的方法，其特征在于，所述方法还包括：远程设备验证所述白名单的有效性。
  8. 如权利要求7所述的方法，其特征在于，所述验证所述白名单的有效性包括以下内容至少一项：验证白名单被控对象与远程设备标识的一致性、验证白名单签发时间是否小于或等于第一阈值、验证白名单签名的一致性。
  9. 如权利要求6至8所述的方法，其特征在于，所述方法还包括：
    远程设备根据所述白名单确定白名单特征值，所述白名单特征值用于标识所述白名单；
    所述远程设备对所述白名单特征值进行签名和/或加密；
    所述远程设备向终端设备发送经过签名和/或加密后的白名单特征值。
  10. 一种远程控制的方法，其特征在于，包括：
    终端设备获取授权令牌；
    所述终端设备向设备管理***发送第一请求信息，所述第一请求信息包括操作请求和所述授权令牌；所述操作请求用于请求所述设备管理***向远程设备下发远控指令，所述授权令牌用于执行所述远控指令的合法性验证。
  11. 如权利要求10所述的方法，其特征在于，所述授权令牌包括授权令牌内容和授权令牌签名信息；
    所述授权令牌内容包括：令牌ID、签发者标识、被授权对象标识、授权内容列表、签发时间、有效期开始时间、有效期结束时间中的至少一项；
    所述授权内容列表包括：被控制对象标识、操作、关键参数中的至少一项；
    所述授权令牌签名信息包括签名数据，或
    所述授权令牌签名信息包括签名数据和签名算法。
  12. 如权利要求10或11所述的方法，其特征在于，所述第一请求信息还包括：白名单，所述白名单包括：白名单内容和白名单签名信息；
    所述白名单内容包括：白名单ID、签发者标识、被授权对象标识、被控制对象、授权令牌ID列表、签发时间中的至少一项；
    所述白名单签名信息包括签名数据或，
    所述白名单签名信息包括签名数据和签名算法。
  13. 如权利要求10至12所述的方法，其特征在于，所述方法还包括：
    终端设备获取白名单，并验证所述白名单的有效性；
    所述验证所述白名单的有效性包括以下内容中至少一项：验证白名单签发者是否有效、验证白名单被授权对象是否有效、验证白名单控制对象是否有效、验证白名单签名是否一致。
  14. 如权利要求13所述的方法，其特征在于，所述方法还包括：
    终端设备保存白名单特征值，所述白名单特征值用于标识所述白名单；
    所述验证所述白名单的有效性包括：所述终端设备使用所述白名单特征值，验证所述白名单的有效性。
  15. 如权利要求14任一项所述的方法，其特征在于，所述方法还包括：
    终端设备从远程设备获取所述白名单特征值；
    所述终端设备对所述白名单特征值进行验证，若通过所述验证，所述终端保存所述白名单特征值。
  16. 如权利要求14或15所述的方法，其特征在于，所述白名单特征值为经过签名和/或加密的白名单特征值。
  17. 如权利要求16所述的方法，其特征在于，所述终端设备对所述白名单特征值进 行验证还包括：对所述白名单特征值进行验签和/或解密。
  18. 如权利要求12至17任一项所述的方法，其特征在于，所述方法还包括：
    终端设备根据用户的操作生成授权令牌内容，并签发授权令牌；
    所述终端设备确定用户操作的任务类型；
    所述终端设备根据所述用户操作的任务类型，确定是否签发新授权令牌和是否更新所述白名单。
  19. 如权利要求12至17任一项所述的方法，其特征在于，所述方法还包括：
    更新密钥；
    终端设备使用更新后的密钥重新签发所述白名单和所述授权令牌；
    所述终端设备向设备管理***发送第三请求信息，所述第三请求信息包括所述重新签发的白名单和授权令牌。
  20. 一种远程控制的方法，其特征在于，包括：
    设备管理***接收第一请求信息，所述第一请求信息包括操作请求和授权令牌；
    所述设备管理***根据所述操作请求生成远控指令，所述远控指令用于指示远程设备执行所述操作请求。
  21. 如权利要求20所述的方法，其特征在于，所述方法还包括：
    设备管理***向远程设备发送第二请求信息，所述第二请求信息包括所述远控指令和所述授权令牌，所述授权令牌用于执行所述远控指令的合法性验证。
  22. 一种远程控制装置，其特征在于，所述装置包括用于执行如权利要求1至21中任一项所述的方法的单元。
  23. 一种远程控制装置，其特征在于，包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行如权利要求1至21中任一项所述的方法。
  24. 一种计算机可读介质，其特征在于，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得所述计算机执行如权利要求1至21中任一项所述的方法。
  25. 一种芯片，其特征在于，包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行如权利要求1至21中任一项所述的方法。
  26. 一种车辆，其特征在于，包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行如权利要求1至9中任一项所述的方法。
PCT/CN2021/134045 2021-11-29 2021-11-29 远程控制的方法和装置 WO2023092563A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2021/134045 WO2023092563A1 (zh) 2021-11-29 2021-11-29 远程控制的方法和装置
CN202180104413.2A CN118235366A (zh) 2021-11-29 2021-11-29 远程控制的方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/134045 WO2023092563A1 (zh) 2021-11-29 2021-11-29 远程控制的方法和装置

Publications (1)

Publication Number Publication Date
WO2023092563A1 true WO2023092563A1 (zh) 2023-06-01

Family

ID=86538752

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/134045 WO2023092563A1 (zh) 2021-11-29 2021-11-29 远程控制的方法和装置

Country Status (2)

Country Link
CN (1) CN118235366A (zh)
WO (1) WO2023092563A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103312515A (zh) * 2013-06-21 2013-09-18 百度在线网络技术（北京）有限公司 授权令牌的生成方法、生成装置、认证方法和认证***
US20170012964A1 (en) * 2014-09-29 2017-01-12 Identity Over Ip Providing authentication of control instructions from a control device to a remotely-controllable physical interaction device using a remote control authentication token
CN107370668A (zh) * 2017-08-25 2017-11-21 北京百度网讯科技有限公司 智能设备远程控制的方法、装置和***
CN108206858A (zh) * 2016-12-16 2018-06-26 杭州零零科技有限公司 一种远程控制方法及***
CN113269931A (zh) * 2021-06-03 2021-08-17 广州大学 一种基于权能的共享汽车访问方法和装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103312515A (zh) * 2013-06-21 2013-09-18 百度在线网络技术（北京）有限公司 授权令牌的生成方法、生成装置、认证方法和认证***
US20170012964A1 (en) * 2014-09-29 2017-01-12 Identity Over Ip Providing authentication of control instructions from a control device to a remotely-controllable physical interaction device using a remote control authentication token
CN108206858A (zh) * 2016-12-16 2018-06-26 杭州零零科技有限公司 一种远程控制方法及***
CN107370668A (zh) * 2017-08-25 2017-11-21 北京百度网讯科技有限公司 智能设备远程控制的方法、装置和***
CN113269931A (zh) * 2021-06-03 2021-08-17 广州大学 一种基于权能的共享汽车访问方法和装置

Also Published As

Publication number Publication date
CN118235366A (zh) 2024-06-21

Similar Documents

Publication Publication Date Title
KR102216322B1 (ko) 디바이스의 보안 프로비저닝 및 관리
CN110637328B (zh) 一种基于便携式设备的车辆访问方法
EP3742696B1 (en) Identity management method, equipment, communication network, and storage medium
KR102244569B1 (ko) 오토모티브 이더넷에 기초하여 차량 내부 네트워크에서 차량 내 디바이스간 통신 방법 및 장치
US10652742B2 (en) Hybrid authentication of vehicle devices and/or mobile user devices
US20190259120A1 (en) Task management of autonomous product delivery vehicles
KR102426930B1 (ko) 차량 공유를 위한 이동통신 단말의 디지털 키를 관리하는 방법 및 이를 이용한 키 서버
US9853973B2 (en) Information distribution system, and server, on-board terminal and communication terminal used therefor
US9577823B2 (en) Rule-based validity of cryptographic key material
JP3920583B2 (ja) 通信セキュリティ保持方法及びその実施装置並びにその処理プログラム
KR102553145B1 (ko) 디지털 키를 처리 및 인증하는 보안 요소 및 그 동작 방법
US20230389095A1 (en) Enhanced wireless connectivity
JP7143744B2 (ja) 機器統合システム及び更新管理システム
WO2023092563A1 (zh) 远程控制的方法和装置
US10635495B2 (en) Method for registering devices, in particular conditional access devices or payment or vending machines, on a server of a system which comprises a number of such devices
CN117040724A (zh) 数字钥匙授权方法、装置、电子设备及可读存储介质
CN112953986A (zh) 一种边缘应用的管理方法及装置
US9712328B2 (en) Computer network, network node and method for providing certification information
CN114697899A (zh) 车辆通信方法、服务器和***以及存储介质
CN115146280B (zh) 一种用于整车ecu的ota安全升级方法及***
WO2024000402A1 (zh) 诊断方法和装置
CN113949432B (zh) 面向飞行任务无人机区块链建立方法、***、设备、终端
EP4024932A1 (en) Method and device for providing an authorization to access an interactive good
CN118138211A (zh) 区块链上的车辆数字密钥管理
JP2007104733A (ja) 通信セキュリティ保持方法及びその実施装置並びにその処理プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21965293

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2021965293

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2021965293

Country of ref document: EP

Effective date: 20240529