Access control method, client device and server device

Abstract

The invention provides an access control method, client equipment and server equipment. The method comprises: a first client device sends binding relationship information to a server device, the binding relationship information being used for indicating that a binding relationship exists between a second client device and a first root certificate, and the binding relationship being used for certificate chain verification when the server device and the second client device establish an operation connection channel. In the embodiment of the invention, when the first client device shares the access authority of the server device with the second client device, the first client device only needs to send the binding relationship between the second client device and the first root certificate to the server device. Therefore, the server device can perform identity verification according to the first root certificate and the second client device. According to the mode, the process that the first client device shares the access permission of the server device to the second client device can be simplified, and the user experience can be improved.

Description

Access control method, client device and server device Technical Field

[0001] The present application relates to the field of Internet of Things technology, and more specifically, to an access control method, a client device, and a server device. Background Art

[0002] To meet multi-user application scenarios, the access rights of server devices can be shared. In related technologies, if a first client device (the server device's administrator device) wants to share the server device's access rights with a second client device, the first client device needs to configure the second client device so that the second client device can access the server device configured by the first client device.

[0003] The above-mentioned sharing method requires the first client device to configure the second client device, which is relatively complicated. If the second client device only needs to access the server device temporarily, this sharing method cannot provide a good user experience.

[0004] Summary of the Invention

[0005] This application provides an access control method, a client device, and a server device. The following introduces various aspects of this application.

[0006] In a first aspect, an access control method is provided, including: a first client device sends binding relationship information to a server device, wherein the binding relationship information is used to indicate that a second client device has a binding relationship with a first root certificate, and the binding relationship is used to perform certificate chain verification when the server device and the second client device establish an operation connection channel.

[0007] In a second aspect, an access control method is provided, including: a server device receives binding relationship information sent by a first client device, the binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used to perform certificate chain verification when the server device and the second client device establish an operation connection channel.

[0008] In a third aspect, an access control method is provided, including: a second client device sends first information to a first client device, the first information being used to determine binding relationship information; wherein, the binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used to perform certificate chain verification when the second client device and the server device establish an operation connection channel.

[0009] In a fourth aspect, a client device is provided, which is a first client device. The first client device includes: a first sending module, used to send binding relationship information to a server device, the binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used to perform certificate chain verification when the server device and the second client device establish an operation connection channel.

[0010] In the fifth aspect, a server device is provided, including: a first receiving module, used to receive binding relationship information sent by a first client device, the binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used to perform certificate chain verification when the server device and the second client device establish an operation connection channel.

[0011] In the sixth aspect, a client device is provided, which is a second client, and the second client device includes: a sending module for sending first information to the first client device, and the first information is used to determine binding relationship information; wherein, the binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used for certificate chain verification when the second client device and the server device establish an operation connection channel.

[0012] In the seventh aspect, a client device is provided, which is a first client device. The first client device includes a processor, a memory, and a communication interface. The memory is used to store one or more computer programs, and the processor is used to call the computer program in the memory so that the first client device executes part or all of the steps in the method of the first aspect.

[0013] In the eighth aspect, a server device is provided, comprising a processor, a memory, and a communication interface, wherein the memory is used to store one or more computer programs, and the processor is used to call the computer program in the memory so that the server device executes part or all of the steps in the method of the second aspect.

[0014] In the ninth aspect, a client device is provided, which is a second client device, and the second client device includes a processor, a memory, and a communication interface, the memory is used to store one or more computer programs, and the processor is used to call the computer program in the memory so that the second client device executes part or all of the steps in the method of the third aspect.

[0015] In a tenth aspect, an embodiment of the present application provides a communication system, which includes the above-mentioned client device and / or server device. In another possible design, the system may also include other devices that interact with the client device or server device in the solution provided in the embodiment of the present application.

[0016] In the eleventh aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program, and the computer program enables a client device or a server device to execute part or all of the steps in the methods of the above aspects.

[0017] In a twelfth aspect, embodiments of the present application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is operable to cause a client device or a server device to perform some or all of the steps of the methods described in each of the above aspects. In some implementations, the computer program product may be a software installation package.

[0018] In the thirteenth aspect, an embodiment of the present application provides a chip, which includes a memory and a processor. The processor can call and run a computer program from the memory to implement some or all of the steps described in the methods of the above aspects.

[0019] In an embodiment of the present application, when a first client device shares access rights to a server device with a second client device, the first client device simply sends the server device the binding relationship between the second client device and the first root certificate. In this way, the server device can authenticate the second client device based on the first root certificate to establish an operational connection channel between the second client device and the server device. This approach can simplify the process of sharing access rights to the server device with the second client device, thereby improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] FIG1 is a diagram illustrating an example of a system architecture of a wireless communication system to which an embodiment of the present application may be applied.

[0021] FIG2 is a model structure of an Internet of Things device to which an embodiment of the present application can be applied.

[0022] FIG3 is a flow chart of a method for sharing access rights of a server device via a cloud platform.

[0023] FIG4 is a flow chart of another method for sharing access rights of a server device via a cloud platform.

[0024] FIG5 is a flow chart of an access control method provided in an embodiment of the present application.

[0025] FIG6 is a flow chart of an access control method provided in another embodiment of the present application.

[0026] FIG7 is a flow chart of an access control method provided in another embodiment of the present application.

[0027] FIG8 is a flow chart of an access control method provided in another embodiment of the present application.

[0028] FIG9 is a flow chart of an access control method provided in yet another embodiment of the present application.

[0029] FIG10 is a schematic diagram of the structure of a client device provided in an embodiment of the present application.

[0030] FIG11 is a schematic diagram of the structure of the server device provided in an embodiment of the present application.

[0031] FIG12 is a schematic structural diagram of a client device provided in another embodiment of the present application.

[0032] FIG13 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0033] Communication system architecture

[0034] FIG1 is a diagram illustrating an exemplary system architecture of a communication system to which embodiments of the present application may be applied. The communication system 100 shown in FIG1 may include a first client device 110 , a second client device 120 , and a server device 130 .

[0035] The first client device 110 can communicate with the server device 130 to access and / or control the server device 130. In some implementations, the first client device 110 can send control information to the server device 130 to control the server device 130. For example, when the server device 130 is a vehicle device or an in-vehicle terminal, the first client device 110 can send control information to the server device 130 to control the opening or closing of the vehicle device or in-vehicle terminal's doors, or to control the air conditioning temperature of the vehicle device or in-vehicle terminal.

[0036] First client device 110 is the administrator device of server device 130. That is, for server device 130, the access control list (ACL) permissions corresponding to first client device 110 are administrator permissions. It should be understood that administrator permissions are the highest level of permissions. A client device (first client device 110) granted administrator permissions can not only read and subscribe to server device 130 resources, execute server device 130's primary functions, and modify and configure data on server device 130, but can also subscribe to and modify server device 130's ACL function cluster.

[0037] It's important to note that the ACL function cluster controls device access permissions. It's deployed on each node and has only one instance. In other words, each node has an ACL. When a node receives a request, it first checks the ACL to see if the requester has permission.

[0038] In some embodiments, the first client device 110 can configure the server device 130. In this case, the first client device 110 can also be understood as a commissioner. The commissioner can be used to configure the server device, for example, to connect the server device to the network, set an owner ID for the server device to associate the server device with a user, and configure the server device with access credentials.

[0039] In some embodiments, the first client device 110 may be a terminal device. The terminal device in the embodiments of the present application may also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, wireless communication device, user agent or user device, etc.

[0040] In the embodiments of the present application, a terminal device may be a device that provides voice and / or data connectivity to a user and can be used to connect people, objects, and machines, such as a handheld device with wireless connection function, a vehicle-mounted device, etc. The terminal device in the embodiments of the present application may be a mobile phone, a tablet computer (Pad), a laptop computer, a PDA, a mobile internet device (MID), a wearable device, a virtual reality (VR) device, an augmented reality (AR) device, a mixed reality (MR) device, a vehicle, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc.

[0041] The first client device 110 may share the access rights of the server device 130 with the second client device 120 , so that the second client device 120 may control the server device 130 .

[0042] Before obtaining the access rights shared by the first client device 110, the second client device 120 cannot communicate with the server device 130, and therefore cannot access and / or control the server device 130. After obtaining the access rights shared by the first client device 110, the second client device 120 can establish a secure connection with the server device 130 based on the access rights, so as to subsequently access and / or control the server device 130.

[0043] In some embodiments, the second client device 120 and the first client device 110 belong to different users. In other words, the second client device 120 and the first client device 110 have different user IDs. For example, the first client device 110 belongs to user A, and the second client device 120 belongs to user B.

[0044] In some embodiments, the second client device 120 may be a terminal device. As one implementation, the second client device 120 and the first client device 110 may be different types of terminal devices, for example, the first client device 110 may be a mobile phone and the second client device 120 may be a computer. As another implementation, the second client device 120 and the first client device 110 may be the same type of terminal device, for example, the first client device 110 and the second client device 120 may both be mobile phones, and both may be owned by different users.

[0045] In some embodiments, the first client device 110 and the second client device 120 may belong to the same ecosystem. In other embodiments, the first client device 110 and the second client device 120 may belong to different ecosystems.

[0046] The server device 130 may refer to an Internet of Things (IoT) device. The server device 130 may refer to an IoT device that supports any IoT protocol, such as an IoT device that supports the Matter standard protocol. For example, IoT devices may include vehicle devices, vehicle-mounted terminals, smart home devices, smart monitoring devices, and the like. Smart home devices may include, for example, smart air conditioners, smart refrigerators, washing machines, rice cookers, and robot vacuums. Smart monitoring devices may include, for example, surveillance cameras, temperature sensors, and sound sensors.

[0047] In some embodiments, a client device (e.g., the first client device 110) that can control the server device 130 can be understood as having a binding relationship with the server device 130. In some embodiments, a client device (e.g., the second client device 120) that cannot control the server device 130 can be understood as not having a binding relationship with the server device 130.

[0048] In some embodiments, the communication system shown in FIG1 may further include a cloud platform 140, which may also be referred to as a cloud computing platform, a cloud, or the like. Cloud platform 140 can be understood as providing network communication capabilities based on hardware and software resources. Therefore, in the embodiments of the present application, first client device 110 can access and / or control server device 130 through cloud platform 140.

[0049] In some implementations, the cloud platform 140 may be built based on one or more cloud servers to provide network functions.

[0050] It should be noted that the cloud platform 140 may also be other systems or devices that can provide network functions, such as a cluster system that can provide network functions, etc. This embodiment of the present application does not limit this.

[0051] It should be understood that Figure 1 exemplarily shows a server device and two client devices. Optionally, the communication system 100 may include multiple server devices, and client devices that have a binding relationship with the server device or client devices that do not have a binding relationship. The embodiments of the present application are not limited to this.

[0052] In some scenarios, the communication system 100 may be, for example, an Internet of Things (IoT) system. The IoT, which stands for "Internet of Everything," can be understood as a network that extends and expands upon the Internet. Various information sensing devices (such as radio frequency identification and global positioning systems) can be used to connect any object to the Internet, forming a massive network for information exchange and communication, thereby enabling interconnection and interoperability between all things.

[0053] Accordingly, in some embodiments, the server device may be an IoT device. The first client device and / or the second client device may also be an IoT device.

[0054] In other embodiments, the cloud platform may be an IoT cloud platform, referred to as "IoT cloud", which is used to provide communication service functions for IoT devices in an IoT system.

[0055] For ease of understanding, system 100 is described using an IoT device as an example. Assume that the first client device 110 is a terminal device 110, the second client device 120 is a terminal device 120, the terminal devices 110 and 120 belong to different users, and the server device 130 is a vehicle device or in-vehicle terminal 130. Continuing with FIG1 , terminal device 110 is the administrator device for the vehicle device or in-vehicle terminal 130 and can configure the vehicle device or in-vehicle terminal 130, for example, by setting the owner ID of the vehicle device or in-vehicle terminal 130 to the ID of terminal device 110, or by configuring access credentials for the vehicle device or in-vehicle terminal 130. Terminal device 110 can share the access rights of the vehicle device or in-vehicle terminal 130 with terminal device 120, for example, via a cloud platform, so that terminal device 120 can establish a secure connection with the vehicle device or in-vehicle terminal 130 based on the shared access rights and access and / or control the vehicle device or in-vehicle terminal 130.

[0056] Data Model for IoT Devices

[0057] The data model of an IoT device can be used to record the resources of the IoT device. An example of a data model for an IoT device is provided below in conjunction with Figure 2. The data model of an IoT device may differ across different IoT protocols, and this is not limited by the present embodiment. Figure 2 illustrates the data model structure of an IoT device applicable to the present embodiment. In the example of Figure 2, the resources of the IoT device can be recorded in a functional cluster.

[0058] 2 , the data model structure 200 of an IoT device includes a node 210 , an endpoint 220 , and a function cluster 230 .

[0059] Node 210 encapsulates a unique, addressable resource on the network, possessing a set of functions and capabilities that users can clearly perceive as a functional entity. Typically, node 210 can be the highest or outermost first-order element in a data model. In other words, node 210 is the only addressable element at the outermost level of a data model.

[0060] A physical entity (e.g., an IoT device) can be a node 210, or in other words, node 210 can refer to an IoT device node. It should be noted that a node can have multiple node identifiers (IDs), and the scope of each node ID is a specific network (fabric). For example, when a node ID is used as the target address for an interaction, the network that specifies the node ID scope is the access network for the interaction.

[0061] A node may include one or more endpoints 220. An endpoint 220 is an instance, which can be a service or a virtual device, as indicated by a device type. Each endpoint 220 conforms to one or more device type definitions, which define the functional clusters supported by the endpoint. In some embodiments, an endpoint can be understood as a service / virtual device indicated by the device type. A functional cluster is an object class instantiated on the endpoint.

[0062] It should be noted that in this architecture model, the device type can be the highest semantic element. The device type defines a set of conformances of the endpoint 220. The device type defines a set of requirements for the node 210 or the endpoint 220.

[0063] Each endpoint 220 may be a collection of a type of functionality, which may include one or more function clusters 230 .

[0064] Functional cluster 230 is a functional building block element of the data model. In some embodiments, functional cluster can also be referred to as functional set, cluster, cluster, etc., which is not limited by the embodiments of the present application. The functional cluster specification defines the client and server that correspond to each other through interaction. Functional cluster 230 can be regarded as an interface, service or object class, which is the lowest independent functional element in the data model. Each functional cluster 230 can be defined by a functional cluster specification, which defines the elements of functional cluster 230. In some embodiments, functional cluster 230 can include attributes, events, commands and behaviors related to the interaction of these elements. In some embodiments, attributes, commands, and events can also be referred to as interface units of functional cluster 230, and corresponding functions can be provided through these three interface units.

[0065] In some embodiments, the attributes, events, commands, and behaviors in a functional cluster 230 are mandatory or optional, depending on the definition of the functional cluster 230 .

[0066] The following briefly introduces the main elements of a function cluster, such as commands, properties, and events, by taking the function cluster including properties, events, and other elements as an example.

[0067] A functional cluster command (also known as a "command") is a set of data fields, each of which is passed between client and server functional cluster instances to invoke behavior on the command recipient. Currently, the protocol stipulates that each command can be listed in a table, which can contain columns for the command's data quality: ID, name, direction, response, access, and conformance. Accordingly, a command can indicate zero or more fields defined in a table. Each command field is defined as a row in the table.

[0068] Attributes are functional cluster data. Currently, the protocol stipulates that each attribute can be listed in a table. The data quality columns of the attribute defined in this table may include: ID, name, (data) type, constraint, other qualities, access, default (value), and compliance. In some implementations, attributes can also define their related semantics and behaviors. Attributes can reflect the queryable / settable state, configuration, and capabilities of a device. In some cases, if no permissions are explicitly defined for an attribute, the default access permissions take effect.

[0069] An event defines a record of something that happened in the past. In this respect, an event record can be thought of as a log entry that provides a chronological view of events on a node through a stream of event records. Unlike attributes, which do not provide any edge-preserving functionality (that is, there is no guarantee that every attribute change will be passed to the observer), events allow each individual edge or change to be captured and reliably passed to the observer. This is critical for safety and security applications that rely on guarantees of correct behavior. Currently, the protocol stipulates that each functional cluster event can be listed in a table, and the data quality columns defined by the table for the event can include: ID, priority, access, and compliance.

[0070] To facilitate understanding, the following describes several common data qualities included in commands, attributes, and events. It should be noted that the commands, attributes, and events in the embodiments of this application may also include other data qualities, or may include portions of the aforementioned data qualities. This is not limited in the embodiments of this application.

[0071] Identifier, which indicates the unique field ID of a field, or the unique identifier of a command (or attribute, event).

[0072] Name: The unique name of the field, or the name of the command (or attribute).

[0073] Type indicates the data type of the field, or the data type of the command parameter (or attribute parameter).

[0074] Direction, usually present in a command list, is used to define the transmission direction of the command. For example, it can be defined as from the client to the server. Another example is from the server to the client.

[0075] Access rights define how an element can be accessed (e.g., read or write) and what permissions are required to access the data. In some implementations, access rights may include V, which indicates that read access or call access requires view permission. Access rights may also include O, which indicates that "read access," "write access," or "call access" requires operation permission. Access rights may also include R, which indicates read access. Access rights may also include W, which indicates write access.

[0076] Response, usually exists in the command list, is used to define the response message of the command.

[0077] Quality, used to define additional data qualities not covered in other columns.

[0078] Default is used to define a default value. It should be noted that the default value is not the value used when the server returns the factory refresh settings. Default values ​​can indicate that the compliance specified for a data field is optional or can change over time. Default values ​​can be defined to fulfill dependencies when the actual data field value does not exist.

[0079] Conformance defines the optionality and dependencies of any data model element or set of elements. Typically, this column is valid for attributes, commands, events, enumerations, and fields of commands, events, or structures. In some implementations, "M" indicates that the corresponding command is part of the basic mandatory feature set, and "O" indicates that the corresponding command is part of the optional feature set.

[0080] For commands, client-to-server command conformance means that the server should recognize and support the client-to-server command and generate responses as defined. Server-to-client command conformance means that the server should send commands in a manner defined by the functional cluster behavior, i.e., respond to client-to-server commands. Command conformance depends on supported server features. Clients should not be required to support optional commands or commands that depend on optional features.

[0081] Constraints include "all" and "desc." "all" in a numeric data type indicates that all values ​​are allowed. "desc" indicates that the constraint is defined in the description section.

[0082] Range indicates the value range of the field. Range can support two forms: explicit constraint and width constraint. Among them, the explicit constraint can give the minimum and maximum values ​​corresponding to the value of the field, for example, the value range of a field is (0,128). The width constraint can limit the value of the field to a specific number of bytes, for example, the value of a field is limited to 8 bytes. In some embodiments, the value of the range may include "N / A" to indicate not applicable. Of course, "N / A" can also appear in other parts (other data quality), such as defaults, constraints, etc.

[0083] Priority: Each event record has an associated priority. This priority can be used to describe the usage semantics of the event.

[0084] Configuration of IoT devices

[0085] After the IoT device is connected to the home network, it will be configured directly. The configuration work can be completed by the onboarding tool (OBT). During the configuration process, the owner ID of the IoT device needs to be set to the device ID of the OBT device. In theory, only devices with the same owner ID can subsequently establish a secure connection and interconnect with each other. In addition, it is also necessary to configure the access credentials of the IoT device. The access credentials can be used for two-way authentication when the two devices establish a connection. The access credentials can be symmetric keys, asymmetric keys, operation certificates, etc. After authentication, the two parties can establish a secure communication connection, that is, they can interconnect and interoperate.

[0086] Sharing access rights to IoT devices

[0087] To meet multi-user application scenarios, the access rights of a server device (e.g., an IoT device) can be shared. As an implementation method, if a first client device (the server device's administrator device) wants to share the server device's access rights with a second client device, the first client device needs to configure the second client device, for example, by setting the second client device's owner ID to the first client device's device ID, or by configuring the second client device's access credentials. In this way, the second client device can access other IoT devices (e.g., the server device) configured by the first client device.

[0088] This sharing method requires the first client device to configure the second client device, which is relatively complex. For example, the first client device needs to interact with the second client device in order to configure access credentials for the second client device. Alternatively, when the first client device shares access rights through the cloud platform, it needs to apply for an access token for the second client device, and the second client device needs to obtain the operation certificate configured for it by the first client device from the cloud platform.

[0089] If the second client device only needs to temporarily access the server device (taking the server device as a car device or a vehicle terminal as an example, the designated driver may need to temporarily access the owner's car device or vehicle terminal), this configuration method using the administrator device cannot provide a good user experience.

[0090] The following describes a solution for sharing access rights through a cloud platform, using Figures 3 and 4. It should be noted that in the examples shown in Figures 3 and 4, the first client device is the administrator device of the server device, and the first client device needs to share the server device's access rights with the second client device. In some embodiments, the server device can be a vehicle device or an in-vehicle terminal.

[0091] Figure 3 is a flow chart of a method for sharing access rights through a cloud platform. As shown in Figure 3, the flow of the method may include steps S301 to S312.

[0092] In step S301 , a first client device applies for a token for a second client device.

[0093] The first client device can send a request to the cloud platform to request (or apply for) a token. The token is used by the second client device to access the cloud platform and obtain an operation certificate. In other words, the token is the identity credential of the second client device when connecting to the cloud platform.

[0094] The request sent by the first client device to the cloud platform should carry the device ID of the second client device. In some embodiments, the request sent by the first client device to the cloud platform may also carry information of the server device, such as the device ID of the server device.

[0095] In step S302 , the cloud platform returns a token to the first client device.

[0096] In step S303 , the first client device sends the token to the second client device.

[0097] The first client device may also carry information of the server device (ie, information of the pre-connected server device) as well as a PIN code (pincode) and a PIN code index (pincodeindex) in the message sending the token.

[0098] In step S304, after generating a public-private key pair, the second client device uses the public key and the token to request an operation certificate from the cloud platform.

[0099] In step S305 , the cloud platform returns the operation certificate to the second client device.

[0100] In step S306 , the first client device learns that the second client device has obtained the operation certificate.

[0101] As one implementation, after the cloud platform returns the operation certificate to the second client device, it can send a message to the first client device to indicate that the second client device has obtained the operation certificate. As another implementation, after the second client device receives the operation certificate sent by the cloud platform, it can send a message to the first client device to indicate that the second client device has obtained the operation certificate.

[0102] In step S307, the first client device establishes a secure connection with the server device.

[0103] As an implementation manner, the first client device and the server device may establish a secure connection via Bluetooth Low Energy.

[0104] In step S308 , the first client device configures the server device.

[0105] The configuration of the server device by the first client device may include PIN code binding configuration (eg, configuring a pin_binding cluster) and / or ACL configuration (eg, configuring an ACL cluster).

[0106] Taking the PIN code binding configuration as an example, the first client device can save the binding relationship between the PIN code, the PIN code index and the device ID of the second client device in the pin_binding cluster. When the second client device establishes a connection with the server device, the corresponding PIN code is used by default to establish the connection.

[0107] Taking ACL configuration as an example, a first client device can set in the ACL cluster which resources of the server device the second client device can access after establishing a connection with the server device. The ACL cluster specifies which devices can access which resources of the server device.

[0108] In step S309 , the first client device notifies the server device to enter a pairing state.

[0109] The server device entering the pairing state is a prerequisite for it to establish a connection with other devices (e.g., client devices or server devices). In other words, only after the server device enters the pairing state can the second client device discover the server device and initiate a connection with it.

[0110] In some embodiments, when the second client device establishes a connection with the server device, it may be necessary to close the connection between the first client device and the server device.

[0111] In step S310, the second client device establishes a data channel connection with the server device, that is, establishes an underlying communication connection.

[0112] In step S311 , the second client device establishes a secure connection with the server device.

[0113] During the process of establishing a secure connection between the second client device and the server device, the operation certificate needs to be verified to perform mutual authentication of the identities of both parties.

[0114] In some embodiments, the second client device and the server device also need to negotiate and generate a shared key to encrypt information and / or data in the secure connection channel based on the shared key.

[0115] In step S312 , the second client device accesses and / or controls the server device based on the established secure connection channel.

[0116] Figure 4 is a flow chart of another method for sharing access rights through a cloud platform. As shown in Figure 4, the flow of the method may include steps S401 to S409.

[0117] In step S401 , a first client device applies for a token for a second client device.

[0118] The first client device may send a request to the cloud platform, the request being used to request (or apply for) a token. The token is used by the second client device to access the cloud platform and obtain an operation certificate.

[0119] The request sent by the first client device to the cloud platform may include one or more of the following information: the device ID of the second client device, the device ID of the server device, the device ID of the first client device, and a signature of the above information using the private key of the first client device.

[0120] As an implementation method, the specific execution process of the above signature can be implemented by generating a token_application structure (token_application Struct), which can be as follows.

[0121] {

[0122] Target: The device ID of the server device / / The operation certificate is used to access the device

[0123] Applicant: Device ID of the first client device / / Applicant for the token

[0124] User: Device ID of the second client device / / User who operates the certificate

[0125] }

[0126] Then, the first client device can use the private key of the first client device to sign the above information to generate a signature (token_application_Sign). In some embodiments, other information such as a timestamp can also be added during the process of generating the signature, which is not limited in the embodiments of the present application.

[0127] In step S402, the first client device establishes a secure connection with the server device.

[0128] As an implementation manner, the first client device and the server device may establish a secure connection via Bluetooth Low Energy.

[0129] In step S403 , the first client device configures the server device and sets the server device to enter a pairing state.

[0130] The configuration of the server device by the first client device may include PIN code binding configuration (eg, configuring a pin_binding cluster) and / or ACL configuration (eg, configuring an ACL cluster).

[0131] Taking the PIN code binding configuration as an example, the first client device can save the binding relationship between the PIN code, the PIN code index and the device ID of the second client device in the pin_binding cluster. When the second client device establishes a connection with the server device, the corresponding PIN code is used by default to establish the connection.

[0132] Taking ACL configuration as an example, a first client device can set in the ACL cluster which resources of the server device the second client device can access after establishing a connection with the server device. The ACL cluster specifies which devices can access which resources of the server device.

[0133] After the first client device has configured the above information, the server device is set to enter the pairing state.

[0134] In step S404, the server device returns an operation success response to the first client device.

[0135] For example, the server device may return a message “200 OK” to the first client device to indicate that the operation of step S403 is successful.

[0136] In step S405 , the first client device sends the following information to the second client device: a token, a device ID of the server device, a PIN code, and an index of the PIN code.

[0137] The token is used by the second client device to apply for an operation certificate, the device ID of the server device is used to indicate the pre-connected server device, and the PIN code and the PIN code index are used by the second client device and the server device for subsequent negotiation of a shared key.

[0138] In some embodiments, the above information may be encrypted using the public key of the second client device and then sent to the second client device.

[0139] In some embodiments, the above information may be sent to the second client device via out-of-band transmission.

[0140] In some embodiments, the above information can be sent to the second client device through a cloud platform or by scanning a QR code.

[0141] In step S406, after generating a public-private key pair, the second client device uses the public key and the token to request an operation certificate from the cloud platform.

[0142] It should be noted that the operation certificate of the second client device generated by the cloud platform may include the signature information (token_application_Sign) reported to the cloud platform in step S401.

[0143] In step S407, the second client device establishes a data channel connection with the server device, that is, establishes an underlying communication connection.

[0144] The second client device can identify the pairing message of the server device by obtaining the device ID of the server device to establish a data channel connection.

[0145] In step S408, the second client device establishes a secure connection with the server device.

[0146] The second client device needs to verify the operation certificate during the process of establishing a secure connection with the server device to perform mutual authentication of the identities of both parties. During the verification process, the second client device needs to send its own operation certificate to the server device for verification.

[0147] In some embodiments, during the verification process, the server device needs to determine whether the signature information (token_application_Sign) in the operation certificate is correct. In other words, the server device needs to confirm that the second client device is authorized to access the server device by the first client device and that the first client device is a high-privilege user of the server device.

[0148] In some embodiments, the second client device and the server device also need to negotiate and generate a shared key to encrypt information and / or data in the secure connection channel based on the shared key.

[0149] In step S409 , the second client device accesses and / or controls the server device based on the established secure connection channel.

[0150] It can be seen from the examples of FIG. 3 and FIG. 4 that the above sharing method requires the first client device to configure the second client device, and this sharing method cannot provide a good user experience.

[0151] To solve the above problems, the present invention provides an access control method, a client device, and a server device, which can simplify the process of sharing access rights of the server device and improve the user experience. The technical solution of the present invention is described in detail below with reference to the accompanying drawings.

[0152] FIG5 is a flow chart of an access control method provided by an embodiment of the present application. The method shown in FIG5 is described from the perspective of interaction between a first client device, a second client device, and a server device. The first client device, the second client device, and the server device may be, for example, the first client device 110, the second client device 120, and the server device 130 shown in FIG1 , respectively.

[0153] The first client device is an administrator device of the server device and can configure the server device. For example, the first client device can configure and modify the ACL function cluster of the server device; or the first client device can subscribe to, read, and modify the resources and data of the server device.

[0154] The first client device may share the access rights of the server device with the second client device, so that the second client device may subsequently access and / or control the server device based on the access rights.

[0155] In some embodiments, the first client device and the second client device may belong to the same ecosystem, for example, they are manufactured by the same manufacturer. In some embodiments, the first client device and the second client device may belong to different ecosystems, for example, they are manufactured by different manufacturers. The server device may belong to the same ecosystem as the first client device / the second client device, or may belong to a different ecosystem, which is not limited in the embodiments of the present application.

[0156] The method shown in FIG5 includes step S520, which is described below.

[0157] In step S520, the first client device sends binding relationship information to the server device.

[0158] The binding relationship information can be used to indicate that a binding relationship exists between the second client device and the first root certificate. This binding relationship is used to perform certificate chain verification when the server device establishes an operational connection channel (also known as a secure connection, secure connection channel, etc.) with the second client device. In other words, the binding relationship can be used to indicate that the server device can use the first root certificate to perform certificate chain verification with the second client device, so that after the certificate chain verification passes, the second client device can access and / or control the server device.

[0159] In the embodiment of the present application, the first root certificate can be used to verify the certificate chain (e.g., operation certificate) of the second client device. The operation certificate will be used as an example in the following description. In other words, the operation certificate of the second client device is issued based on the first root certificate. After the first client device sends the binding relationship information to the server device, the server device can subsequently determine the first root certificate corresponding to the second client device based on the binding relationship, thereby using the first root certificate to verify the operation certificate of the second client device, so as to establish an operation connection channel with the second client device after passing the certificate chain verification.

[0160] In some embodiments, the first root certificate may be the root certificate of the second client device. In this case, it can be considered that the operation certificate of the second client device may be issued based on the root certificate of the second client device. In other words, the second client device can generate its own operation certificate without the first client device configuring the operation certificate for the second client device. The first client device can then obtain the root certificate of the second client device and verify the operation certificate of the second client device based on the root certificate of the second client device.

[0161] However, the present invention is not limited to this embodiment, as long as the first root certificate can be used to verify the operation certificate of the second client device. For example, the operation certificate of the second client device may be issued by a trusted manufacturer other than the manufacturer of the second client device, and the first root certificate may be the root certificate corresponding to the trusted manufacturer that issued the operation certificate of the second client device.

[0162] In some embodiments, after determining the binding relationship information, the first client device may check whether the server device stores the first root certificate. If the server device does not store the first root certificate, the first client device may also send the first root certificate to the server device so that the server device can subsequently use the first root certificate to verify the identity of the second client device. If the server device stores the first root certificate, the first client device only needs to send the above binding relationship information to the server device.

[0163] The embodiment of the present application does not specifically limit the implementation method for the first client device to obtain the first root certificate. The first client device can obtain the first root certificate through various trusted methods. As an implementation method, the manufacturer of the first client device and the manufacturer of the second client device can conduct business negotiations or commercial cooperation to exchange the manufacturer's root certificates. As another implementation method, the manufacturer of the first client device and the manufacturer of the second client device can form a blockchain and store their respective root certificates on the blockchain for exchange. As another trusted implementation method, the manufacturer of the first client device and the manufacturer of the second client device can store each other's root certificates on a trusted public cloud so that the other party can obtain them in a trusted manner, etc.

[0164] In this way, when the first client device shares the access rights of the server device with the second client device, it is not necessary to configure the operation certificate for the second client device. It only needs to obtain the first root certificate corresponding to the operation certificate of the second client device and associate the first root certificate with the second client device.

[0165] That is, in this embodiment of the present application, when a first client device shares access rights to a server device with a second client device, the first client device simply sends the server device the binding relationship between the second client device and the first root certificate. In this way, the server device can authenticate the second client device based on the first root certificate to establish an operational connection channel between the second client device and the server device. This approach can simplify the process of sharing access rights to a server device with a second client device, thereby improving the user experience.

[0166] In some embodiments, the binding relationship information sent by the first client device to the server device can be recorded in a first functional cluster of the server device. As an implementation method, the first functional cluster can include a first attribute, and the first client device can complete the binding of the first root certificate and the second client device by setting the first attribute.

[0167] Taking the first functional cluster as an operational credential functional cluster (Operational Credentials Cluster) as an example, the operational credential functional cluster may include a first attribute, for example, the first attribute is a trusted root certificate (TrustrootCert) attribute. The first client device can complete the binding of the first root certificate and the second client device by setting the first attribute (such as the TrustrootCert attribute). It should be noted that the embodiment of the present application does not limit the names of the first functional cluster and the first attribute, as long as the first attribute is used to record the above-mentioned binding relationship information.

[0168] In some embodiments, the first attribute may record the correspondence between the device identification of the second client device and the first root certificate. Only when the correspondence is saved on the server device, can the server device use the first root certificate to verify the certificate chain of the second client device (for example, the operation certificate) according to the correspondence, and establish a secure connection with the second client device. As a specific implementation method, the first attribute may record the relationship pair {rootCert, PeerNodeIDList} between the first root certificate and the peer device ID. Only when this relationship pair is saved on the server device, can the server device verify the certificate chain of the peer according to rootCert and establish a secure connection with the peer. It should be understood that the peer device may refer to one or more devices. For example, the peer device may include the second client device and other client devices, and the certificate chains of the second client device and other client devices are all issued based on the first root certificate. In other words, the PeerNodeIDList in the above relationship pair {rootCert, PeerNodeIDList} may be one or more NodeIDs.

[0169] When establishing an operation connection channel with a peer device, the server device needs to check whether the server device has saved the first root certificate corresponding to the peer device and the NodeID of the peer device. If not, the two cannot establish an operation connection channel.

[0170] 5 , in some embodiments, before step S520 , the method may further include step S510 . In step S510 , the second client device sends first information to the first client device . The first information is used to determine the binding relationship information.

[0171] In some embodiments, the first information can be used to indicate the identity of the second client device and related information of the first root certificate. For example, the first information may include the device identifier (NodeID) of the second client device to indicate the identity of the second client device; or, the first information may include the vendor identifier (VendorID) of the second client device and / or the application identifier (APPID) of the second client device to indicate related information of the first root certificate. As an example, if all devices corresponding to the manufacturer of the second client device use the same root certificate, the first client device can determine the first root certificate based on the vendor identifier of the second client device. As another example, if devices of different product types corresponding to the manufacturer of the second client device use the same root certificate, the first client device can determine the first root certificate based on the vendor identifier and application identifier of the second client device.

[0172] It should be understood that the device identifier of the second client device should be unique. As an implementation, the device identifier of the second client device may include the manufacturer identifier of the second client device and a unique code within the manufacturer. It should be noted that the manufacturer identifier of the second client device here may be different from the manufacturer identifier of the second client device included in the first information mentioned above, but both must ensure uniqueness within the system.

[0173] In some embodiments, the first information may further include other content, which is not limited in the embodiments of the present application. For example, the first information may further include one or more of the following information: a public key of the second client device, an identity code of the second client device, and a first signature.

[0174] The identity code of the second client device can be used by the second client device to access the server device. That is, the identity code can be used to subsequently establish an operational connection channel between the second client device and the server device. For example, the identity code can be used to subsequently negotiate a shared key between the second client device and the server device, and then transmit control information based on the negotiated shared key.

[0175] The first signature can be obtained by the second client device using the private key of the second client device to sign one or more of the following information: the manufacturer identification of the second client device, the application identification of the second client device, the device identification of the second client device, the public key of the second client device, and the identity code of the second client device, etc.

[0176] The public key of the second client device can be used by the first client device to decrypt the first signature sent by the second client device, so as to verify the identity of the second client device and the authenticity of the message.

[0177] In some embodiments, the first information may be provided by the second client device to the first client device through out-of-band transmission.

[0178] In some embodiments, the first client device may obtain the first information by scanning a QR code, or the first client device and the second client device may obtain the first information by using near field communication (NFC).

[0179] In some embodiments, after obtaining the first information, the first client device may establish a secure connection channel with the server device to configure the server device based on the secure connection channel, for example, configure the binding relationship information described above.

[0180] In some embodiments, in addition to configuring the binding relationship information between the second client device and the first root certificate to the server device, the first client device may also configure other content. For example, the first client device may configure the second client device's access rights to the server device to the server device. As an implementation method, the first client device may set an ACL function cluster of the server device to increase the second client device's access rights to the server device. It should be noted that the ACL function cluster records the correspondence between the peer device identifier and the list of local function clusters that are allowed to be accessed, that is, the ACL function cluster can be used to indicate which function clusters of the local end the peer device has what kind of access rights to. In other words, only peer devices that are recorded in the ACL function cluster of the server device can access the corresponding local functions, while other local functions that are not recorded cannot be accessed by the peer device.

[0181] In this way, after the first client device adds the correspondence between the device identifier of the second client device and the corresponding function cluster of the server device that the second client device can access to the ACL function cluster of the server device, the second client device can subsequently access and / or control the corresponding function cluster.

[0182] 6 is a flowchart of an access control method according to another embodiment of the present application. In some embodiments, the first client device may also send the identity code of the second client device to the server device so that the second client device can access the server device using the identity code.

[0183] Specifically, in step S610, the first client device sends the identity code of the second client device to the server device.

[0184] As mentioned above, the identity code of the second client device can be used by the second client device to access the server device using the identity code. Specifically, the identity code of the second client device can be used by the second client device and the server device (the two parties establishing the operation connection channel) to negotiate a shared key to avoid the problem of information leakage during the negotiation of the shared key.

[0185] In step S620 , the server device sends the index of the identity code to the first client device.

[0186] To avoid the potential leakage of identity codes when the second client device and the server device directly transmit the identity code, the second client device and the server device can use the identity code to encrypt information during the transmission process of the negotiated shared key, and use the identity code index to indicate which identity code the other party is using. As an implementation method, the server device and the second client device can store a correspondence between the identity code and the identity code index. This allows both parties to determine which identity code was used to encrypt the information transmitted by the other party based on the identity code index, and then use the corresponding identity code to decrypt it.

[0187] Therefore, both the server device and the second client device need to store the correspondence between the identity code and the identity code index. As a possible implementation, the first client device can send the identity code to the server device. After the server device determines the identity code index corresponding to the identity code, it subsequently notifies the first client device and / or the second client device of the identity code index.

[0188] In some embodiments, the server device may include a second function cluster (eg, PincodeInfo function cluster), which may include a second attribute that records a correspondence between an identity code of the second client device and an index of the identity code.

[0189] In some embodiments, the second functional cluster may be a different functional cluster from the first functional cluster described above. In some embodiments, the second functional cluster may be the same functional cluster as the first functional cluster, which is not limited in the embodiments of the present application.

[0190] In some embodiments, steps S610 and S620 are performed after the first client device receives the first information sent by the second client device, that is, steps S610 and S620 may be performed after step S510. The present embodiment of the application does not specifically limit the execution order of steps S610-step S620 and the aforementioned step S520. Step S520 may be performed before steps S610-step S620, after steps S610-step S620, or simultaneously with steps S610-step S620.

[0191] Referring to FIG. 7 , in some embodiments, the method provided in the embodiment of the present application may further include step S710 and step S720.

[0192] In step S710, a first client device sends a first command to a server device. The first command is used by the server device to broadcast parameters of the first command.

[0193] In some embodiments, the first command may also be referred to as a pairing command.

[0194] In some embodiments, the parameters of the first command may include one or more of the following: an index of the identity code of the second client device, a device identifier of the second client device, a manufacturer identifier of the first client device, an application identifier of the first client device, a broadcast time of the parameters of the first command, and encryption methods supported by the server device. In other words, the first command may carry one or more of the above information so that the server device can broadcast the above information during broadcast.

[0195] After the second client device learns the index of the identity code of the second client device, it can store the index of the identity code in correspondence with the identity code, so as to subsequently negotiate a shared key with the server device based on the identity code and the index of the identity code.

[0196] In some embodiments, the second client device can determine the root certificate (e.g., a second root certificate) corresponding to the first client device based on the manufacturer identifier of the first client device and / or the application identifier of the first client device. The second root certificate can be used to authenticate the certificate chain of the server device when the second client device establishes an operational connection channel with the server device.

[0197] In some embodiments, if all devices corresponding to the manufacturer of the first client device use the same root certificate, the second client device can determine the second root certificate based on the manufacturer identifier of the first client device. In some embodiments, if devices of different product types corresponding to the manufacturer of the first client device use the same root certificate, the second client device can determine the second root certificate based on the manufacturer identifier and application identifier of the first client device.

[0198] In some embodiments, if the second client device does not store the second root certificate corresponding to the first client device, the second client device needs to obtain the second root certificate so that the certificate chain verification can be performed when the operation connection channel is subsequently established with the server device. The embodiment of the present application does not limit the implementation method of the second client device obtaining the second root certificate, and it can obtain the second root certificate in any trusted manner. For the specific implementation method of obtaining the second root certificate, please refer to the implementation method of the first client device obtaining the first root certificate mentioned above, which will not be repeated here.

[0199] The broadcast time of the parameters of the first command can be used to indicate the duration for which the server device broadcasts the parameters of the first command. This application does not limit the specific duration of the broadcast time of the parameters of the first command. For example, the unit of the broadcast time can be seconds (s), such as 15s, 30s, 60s, etc.

[0200] The server device may support one or more encryption methods. For example, the server device may support encryption methods corresponding to universal cryptographic primitives and / or encryption methods corresponding to Chinese cryptographic primitives. After the server device broadcasts the encryption methods it supports, the second client device may select an appropriate encryption method based on the encryption methods supported by the server device to communicate with the server device.

[0201] The following is an exemplary introduction to the parameters of the first command in conjunction with Table 1 and Table 2.

[0202] Table 1

[0203]

[0204] Table 1 lists the parameters of the first command. It should be understood that the parameters of the first command may include one or more of the parameters listed in Table 1. Of course, the parameters of the first command may also include other parameters in addition to the parameters listed in Table 1, and the embodiments of the present application are not limited to this. For example, the parameters of the first command may also include the device identifier of the first client device.

[0205] The data type of the multicast identity code in Table 1 may be a list (a structure), such as the PinIndexInfo list shown in Table 1. The specific content of the list can be found in Table 2.

[0206] Table 2

[0207]

[0208] See Table 2. The PinIndexInfo list contains the correspondence between the identity code index (PinIndex) and the peer device's device identifier (PeerNodeID). In this way, after receiving the broadcast message from the server device, the second client device can determine the corresponding identity code index based on the peer device's device identifier.

[0209] That is to say, the second client device can save the correspondence between the identity code of the second client device and the index of the identity code according to the parameters of the first command, and the server device will also save the correspondence between the identity code of the second client device and the index of the identity code, so that the two can subsequently use the identity code of the second client device and the index of the identity code to negotiate a shared key and establish an operation connection channel.

[0210] In step S720, the server device broadcasts the parameters of the first command. In other words, in step S720, the server device may send a pairing broadcast, which may carry the parameters of the first command.

[0211] In some embodiments, before sending the broadcast, the server device may set the current state of the server device to a pairing state. For example, the server device may set the current state of the server device to a pairing state based on a command from the first client device.

[0212] In some embodiments, after receiving the broadcast from the server device, the second client device may establish an operational connection channel with the server device based on the parameters of the broadcasted first command.

[0213] In some embodiments, after step S720, the method may further include step S730. In step S730, the server device receives a second command, where the second command is used by the server device to broadcast parameters of the second command. In some embodiments, the second command may be understood as another pairing command received by the server device.

[0214] The parameters of the second command are similar to those of the first command. For example, the parameters of the second command may include the index of the identity code of the object (such as the second client device) that receives the broadcast message of the server device, the device identifier of the object that receives the broadcast message of the server device, the device identifier of the initiator of the second command (such as the first client device), the application identifier of the initiator of the second command, the broadcast time of the second command, and the encryption method supported by the server device, etc.

[0215] In some embodiments, the initiator of the second command may be the same as the initiator of the first command. In some embodiments, the initiator of the second command may be different from the initiator of the first command.

[0216] In some embodiments, the second command and the first command may be the same, for example, the parameters of the second command and the parameters of the first command are the same. In some embodiments, the second command and the first command may be different, for example, the parameters of the second command and the parameters of the first command are different.

[0217] In some embodiments, after step S730, the server device may further perform step S740. Step S740 may include one or more of steps S740a to S740c.

[0218] In step S740a, if the initiator of the first command and the second command is the same, the server device may merge the parameters of the first command with the parameters of the second command, and broadcast the parameters of the merged command.

[0219] As an implementation manner, the server device may determine whether the initiators of the first command and the second command are the same according to the application identifier of the command initiator and / or the manufacturer identifier of the command initiator carried in the first command and the second command respectively.

[0220] In some embodiments, the server device merges the parameters of the first command and the parameters of the second command, and broadcasts the parameters of the merged command, which may mean that the server device can merge the parameters of the second command with the multicast identity code list (PinIndex, PeerNodeID) in the parameters of the first command, and broadcast the parameters of the merged command.

[0221] In some embodiments, the server device merges the parameters of the first command with the parameters of the second command and broadcasts the merged command parameters. This may mean that the server device may merge the parameters of the second command with the multicast identity code list (PinIndex, PeerNodeID) in the parameters of the first command, and the broadcast time is the larger of the remaining broadcast time corresponding to the first command and the broadcast time corresponding to the second command. However, the embodiments of the present application are not limited to this, and the broadcast time may also be the sum of the remaining broadcast time corresponding to the first command and the broadcast time corresponding to the second command.

[0222] In step S740b, the server device broadcasts the parameters of the first command and the parameters of the second command in turn.

[0223] As an implementation, the server device may broadcast the parameters of the first command and the parameters of the second command alternately within a fixed period. For example, the server device may broadcast the parameters of the first command per unit time, then broadcast the parameters of the second command per unit time, and then broadcast the parameters of the first command again per unit time, etc.

[0224] In this embodiment, the initiators of the first command and the second command may be the same or different. In this embodiment, the first command and the second command may be the same or different, and this embodiment of the application does not limit this.

[0225] In step S740c, if the first command and the second command are different, the server device sends a response message to the initiator of the second command.

[0226] In some embodiments, the response message may be used to instruct the initiator of the second command to wait for broadcasting parameters of the second command. In some embodiments, the response message may be used to instruct the initiator of the second command whether to finish broadcasting parameters of the first command.

[0227] In this embodiment, the initiator of the first command and the initiator of the second command may be the same or different, and this is not limited in the present embodiment.

[0228] For ease of understanding, two specific embodiments are given below. It should be noted that the following embodiments are only examples and are not intended to limit the technical solutions of this application. The following example uses a vehicle device or a vehicle-mounted terminal as the server device, APP_A as the first client device, and APP_B as the second client device. APP_A is the administrator of the vehicle device or the vehicle-mounted terminal, and APP_A can share the access rights of the vehicle device or the vehicle-mounted terminal with APP_B.

[0229] In some embodiments, APP_A and APP_B may belong to different ecosystems or the same ecosystem.

[0230] Example 1:

[0231] Figure 8 is a flow chart of an access control method provided by another embodiment of the present application. As shown in Figure 8, the method may include steps S801 to S809.

[0232] In step S801, APP_A obtains first information in an out-of-band manner.

[0233] The first information may include one or more of the following: manufacturer identification of APP_B; application identification of APP_B; device identification of APP_B; public key of APP_B; public key generated by APP_B, and a first signature obtained by signing the above information using the private key of APP_B.

[0234] In step S802, APP_A establishes a secure connection (negotiates a session key) with the vehicle device or the vehicle-mounted terminal.

[0235] In step S803, APP_A sends binding relationship information to the vehicle device or the vehicle terminal.

[0236] As an implementation method, APP_A sets the first attribute in the first function cluster on the vehicle device or the vehicle terminal to complete the binding of the first root certificate corresponding to APP_B and the device identifier of APP_B.

[0237] In some embodiments, the first attribute stores the relationship pair {rootCert, PeerNodeIDList} between the first root certificate and the peer device ID. Only when this relationship pair is stored on the vehicle device or vehicle terminal can the certificate chain of the peer end be verified based on the first root certificate (rootCert) and a secure connection be established with the peer end. PeerNodeIDList is one or more NodeIDs. When establishing a connection between the vehicle device or vehicle terminal and the peer device, it is necessary to check whether the local end has stored the first root certificate and NodeID of the peer end; otherwise, a secure connection cannot be established.

[0238] In some embodiments, if the vehicle device or the vehicle terminal does not store the first root certificate, APP_A may also send the first root certificate to the vehicle device or the vehicle terminal.

[0239] In step S804, APP_A sets the ACL function cluster and increases the permission for APP_B to access the vehicle equipment or vehicle terminal.

[0240] In step S805, APP_A sets the identity code generated by APP_B obtained in step S801 to the second function cluster (eg, PincodeInfo function cluster), and obtains the index of the identity code in the response message.

[0241] The second function cluster records the corresponding relationship between the identity code and the index of the identity code.

[0242] In some embodiments, APP_A needs to confirm whether to use the identity code information provided by the second client device.

[0243] In step S806, APP_A sends a first command (eg, a pairing command) to the vehicle device or the vehicle terminal.

[0244] The first command may carry information such as the index of the identity code obtained in step S805, the manufacturer identifier of APP_A, the application identifier of APP_A, and the device identifier of APP_B.

[0245] APP_B can determine whether it already has the second root certificate corresponding to APP_A based on APP_A's vendor identifier and / or APP_A's application identifier. If APP_B does not store the second root certificate, it needs to obtain the second root certificate to perform certificate chain verification when establishing a connection.

[0246] In step S807 , the vehicle device or the vehicle terminal sends a pairing broadcast, which carries the parameters of the first command (ie, the information in step S806 ) in the broadcast.

[0247] In step S808, the vehicle device or the vehicle terminal sets the current state of the vehicle device or the vehicle terminal to a pairing state.

[0248] In step S809, APP_B establishes an operation connection channel with the vehicle device or the vehicle terminal.

[0249] Example 2:

[0250] The second embodiment is mainly applied to an execution strategy when a broadcast pairing command (eg, parameters of a second command) is received again during the process of broadcasting a pairing command (eg, parameters of a first command) by a vehicle device or a vehicle terminal.

[0251] Figure 9 is a flowchart of an access control method provided by another embodiment of the present application. The method shown in Figure 9 may include steps S901 to S914.

[0252] For steps S901 to S908 , reference may be made to the description of steps S801 to S808 above.

[0253] In step S909 , APP_B receives the second command.

[0254] After receiving the second command, APP_B may execute one or more of the following steps S910 to S913, for example, step S910 and step S911, or step S912, or step S913.

[0255] In step S910 , APP_B determines whether the first command and the second command are commands sent by the same APP.

[0256] As an implementation manner, APP_B may be determined according to the application identifier and the manufacturer identifier carried in the first command and the second command respectively.

[0257] In step S911, if the commands are sent by the same APP, APP_B can merge them and send them. For example, APP_B can merge the second command with the List(PinIndex, PeerNodeID) in the first command, and use the larger broadcast time of the first command and the second command.

[0258] In step S912, APP_B broadcasts the parameters of the first command and the parameters of the second command in turn.

[0259] As an implementation method, the parameters of the first command and the parameters of the second command can be broadcast alternately within a fixed period, for example, broadcast the parameters of the first command per unit time, broadcast the parameters of the second command per unit time, and broadcast the parameters of the first command per unit time again.

[0260] In step S913, if the second command is different from the first command, APP_B adds the parameters of the second command to the broadcast list to be sent, and sends a response message to the initiator of the second command, indicating whether to wait for or receive the broadcast of the parameters of the first command.

[0261] In step S914, APP_B establishes an operation connection channel with the vehicle device or the vehicle terminal.

[0262] The method embodiment of the present application is described in detail above in conjunction with Figures 1 to 9 . The device embodiment of the present application is described in detail below in conjunction with Figures 10 to 13 . It should be understood that the description of the method embodiment corresponds to the description of the device embodiment. Therefore, for portions not described in detail, reference can be made to the above method embodiment.

[0263] FIG10 is a schematic diagram of the structure of a client device provided in an embodiment of the present application. The client device can be any of the first client devices described above. The first client device 1000 shown in FIG10 can include a first sending module 1010.

[0264] The first sending module 1010 can be used to send binding relationship information to the server device, where the binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate. The binding relationship is used to perform certificate chain verification when the server device and the second client device establish an operation connection channel.

[0265] Optionally, the first client device 1000 also includes: a first receiving module 1020, used to receive first information sent by the second client device, the first information is used to determine the binding relationship information; wherein, the first information is used to indicate the identity of the second client device and related information of the first root certificate.

[0266] Optionally, the first information includes one or more of the following information: the manufacturer identifier of the second client device, the application identifier of the second client device, the device identifier of the second client device, the public key of the second client device, the identity code of the second client device, and the first signature.

[0267] Optionally, the first information is provided by the second client device through out-of-band transmission.

[0268] Optionally, the binding relationship information is recorded in a first functional cluster, the first functional cluster includes a first attribute, and the first attribute records a correspondence between the device identifier of the second client device and the first root certificate.

[0269] Optionally, the first client device 1000 further includes: a second sending module, configured to send the first root certificate to the server device.

[0270] Optionally, the first client device 1000 further includes: a third sending module for sending the identity code of the second client device to the server device, wherein the identity code is used by the second client device to access the server device; and a second receiving module for receiving the index of the identity code sent by the server device.

[0271] Optionally, the server device includes a second functional cluster, the second functional cluster includes a second attribute, and the second attribute records a correspondence between the identity code and an index of the identity code.

[0272] Optionally, the first client device 1000 further includes: a fourth sending module, configured to send a first command to the server device, where the first command is used for the server device to broadcast parameters of the first command.

[0273] Optionally, the parameters of the first command include one or more of the following: an index of the identity code of the second client device, a device identifier of the second client device, a manufacturer identifier of the first client device, an application identifier of the first client device, a broadcast time of the parameters of the first command, and an encryption method supported by the server device.

[0274] Optionally, the first client device 1000 further includes: a fifth sending module, configured to send a second command to the server device, where the second command is used for the server device to broadcast parameters of the second command.

[0275] Optionally, the first client device 1000 also includes: a third receiving module, used to receive a response message sent by the server device if the first command and the second command are different, the response message being used to indicate that the first client device is waiting to broadcast the parameters of the second command, or the response message being used to indicate whether the first client device has finished broadcasting the parameters of the first command.

[0276] Optionally, the server device is a vehicle device or a vehicle-mounted device.

[0277] Optionally, the first sending module 1010 may be a transceiver 1330. The first client device 1000 may further include a processor 1310 and a memory 1320, as specifically shown in FIG13 .

[0278] FIG11 is a schematic diagram of the structure of a server device according to an embodiment of the present application. The server device 1100 shown in FIG11 may include a first receiving module 1110 .

[0279] The first receiving module 1110 can be used to receive binding relationship information sent by the first client device, where the binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used to perform certificate chain verification when the server device and the second client device establish an operation connection channel.

[0280] Optionally, the binding relationship information is determined according to first information, where the first information is used to indicate the identity of the second client device and related information of the first root certificate.

[0281] Optionally, the first information includes one or more of the following information: the manufacturer identifier of the second client device, the application identifier of the second client device, the device identifier of the second client device, the public key of the second client device, the identity code of the second client device, and the first signature.

[0282] Optionally, the first information is provided by the second client device through out-of-band transmission.

[0283] Optionally, the binding relationship information is recorded in a first functional cluster, the first functional cluster includes a first attribute, and the first attribute records a correspondence between the device identifier of the second client device and the first root certificate.

[0284] Optionally, the server device 1100 further includes: a second receiving module 1120, configured to receive the first root certificate sent by the first client device.

[0285] Optionally, the server device 1100 further includes: a third receiving module for receiving the identity code of the second client device sent by the first client device, wherein the identity code is used by the second client device to access the server device; and a first sending module for sending an index of the identity code to the first client device.

[0286] Optionally, the server device includes a second functional cluster, the second functional cluster includes a second attribute, and the second attribute records a correspondence between the identity code and an index of the identity code.

[0287] Optionally, the server device 1100 further includes: a fourth receiving module, configured to receive a first command, where the first command is used by the server device to broadcast parameters of the first command; and a first broadcasting module, configured to broadcast parameters of the first command.

[0288] Optionally, the parameters of the first command include one or more of the following: an index of the identity code of the second client device, a device identifier of the second client device, a manufacturer identifier of the first client device, an application identifier of the first client device, a broadcast time of the parameters of the first command, and an encryption method supported by the server device.

[0289] Optionally, the server device 1100 further includes: a fifth receiving module, configured to receive a second command, where the second command is used by the server device to broadcast parameters of the second command.

[0290] Optionally, the server device 1100 further includes: a merge broadcast module, configured to merge the parameters of the first command and the parameters of the second command if the initiators of the first command and the second command are the same, and broadcast the parameters of the merged command.

[0291] Optionally, the server device 1100 further includes: a second broadcast module, configured to broadcast parameters of the first command and parameters of the second command in turn.

[0292] Optionally, the server device 1100 also includes: a second sending module, used to send a response message to the initiator of the second command if the first command and the second command are different, the response message being used to indicate the initiator of the second command to wait for broadcasting the parameters of the second command, or the response message being used to indicate whether the initiator of the second command has finished broadcasting the parameters of the first command.

[0293] Optionally, the server device is a vehicle device or a vehicle-mounted device.

[0294] Optionally, the first receiving module 1110 may be a transceiver 1330. The server device 1100 may further include a processor 1310 and a memory 1320, as shown in FIG13 .

[0295] FIG12 is a schematic diagram of the structure of a client device provided in another embodiment of the present application. The client device can be any of the second client devices described above. The second client device 1200 shown in FIG12 can include a sending module 1210.

[0296] The sending module 1210 can be used to send first information to the first client device, and the first information is used to determine the binding relationship information; wherein, the binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used to perform certificate chain verification when the second client device and the server device establish an operation connection channel.

[0297] Optionally, the first information is used to indicate the identity of the second client device and related information of the first root certificate.

[0298] Optionally, the first information includes one or more of the following information: the manufacturer identifier of the second client device, the application identifier of the second client device, the device identifier of the second client device, the public key of the second client device, the identity code of the second client device, and the first signature.

[0299] Optionally, the first information is provided by the second client device through out-of-band transmission.

[0300] Optionally, the binding relationship information is recorded in a first functional cluster, the first functional cluster includes a first attribute, and the first attribute records a correspondence between the device identifier of the second client device and the first root certificate.

[0301] Optionally, the second client device 1200 further includes: a receiving module 1220 for receiving parameters of a first command broadcast by the server device; and an establishing module 1230 for establishing an operation connection channel with the server device based on the parameters of the first command.

[0302] Optionally, the parameters of the first command include one or more of the following: an index of the identity code of the second client device, a device identifier of the second client device, a manufacturer identifier of the first client device, an application identifier of the first client device, a broadcast time of the parameters of the first command, and an encryption method supported by the server device.

[0303] Optionally, the server device is a vehicle device or a vehicle-mounted device.

[0304] Optionally, the sending module 1210 may be a transceiver 1330. The second client device 1200 may further include a processor 1310 and a memory 1320, as specifically shown in FIG13 .

[0305] Figure 13 is a schematic block diagram of a communication device according to an embodiment of the present application. The dashed lines in Figure 13 indicate that the unit or module is optional. Apparatus 1300 may be used to implement the method described in the above method embodiment. Apparatus 1300 may be a chip, a client device, or a server device.

[0306] The device 1300 may include one or more processors 1310. The processor 1310 may support the device 1300 to implement the method described in the above method embodiment. The processor 1310 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be another general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0307] The apparatus 1300 may further include one or more memories 1320. The memories 1320 store programs that can be executed by the processor 1310, causing the processor 1310 to perform the methods described in the above method embodiments. The memories 1320 may be independent of the processor 1310 or integrated into the processor 1310.

[0308] The apparatus 1300 may further include a transceiver 1330. The processor 1310 may communicate with other devices or chips via the transceiver 1330. For example, the processor 1310 may transmit and receive data with other devices or chips via the transceiver 1330.

[0309] The present application also provides a computer-readable storage medium for storing a program. The computer-readable storage medium can be applied to a client device or a server device provided in the present application, and the program causes a computer to execute the method performed by the client device or the server device in each embodiment of the present application.

[0310] The present application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to the client device or server device provided in the present application, and the program causes a computer to execute the methods performed by the client device or server device in various embodiments of the present application.

[0311] The present application also provides a computer program that can be applied to the client device or server device provided in the present application, and enables a computer to execute the method performed by the client device or server device in each embodiment of the present application.

[0312] It should be understood that the terms "system" and "network" in this application can be used interchangeably. In addition, the terms used in this application are only used to explain the specific embodiments of this application and are not intended to limit this application. The terms "first", "second", "third", and "fourth" in the specification and claims of this application and the accompanying drawings are used to distinguish different objects rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.

[0313] In the embodiments of this application, the term "indication" may refer to a direct indication, an indirect indication, or an indication of an association. For example, "A indicates B" may refer to a direct indication of B, e.g., B can obtain information through A; it may refer to an indirect indication of B, e.g., A indicates C, e.g., B can obtain information through C; or it may refer to an association between A and B.

[0314] In the embodiment of the present application, "B corresponding to A" means that B is associated with A and B can be determined based on A. However, it should be understood that determining B based on A does not mean determining B based solely on A, but B can also be determined based on A and / or other information.

[0315] In the embodiments of the present application, the term "corresponding" may indicate a direct or indirect correspondence between the two, or an association relationship between the two, or a relationship between indication and indication, configuration and configuration, etc.

[0316] In the embodiments of the present application, "pre-defined" or "pre-configured" can be implemented by pre-saving corresponding codes, tables, or other methods that can be used to indicate relevant information in devices (for example, including client devices and server devices). The present application does not limit the specific implementation method. For example, pre-defined can refer to what is defined in the protocol.

[0317] In the embodiments of the present application, the “protocol” may refer to a standard protocol in the communications field, for example, it may include an LTE protocol, an NR protocol, and related protocols used in future communication systems, and the present application does not limit this.

[0318] In the embodiments of this application, the term "and / or" is simply a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0319] In various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0320] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0321] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0322] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0323] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be read by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0324] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. An access control method, characterized in that: include: The first client device sends binding relationship information to the server device, where the binding relationship information is used to indicate that a binding relationship exists between the second client device and the first root certificate, and the binding relationship is used to perform certificate chain verification when the server device and the second client device establish an operation connection channel.

2. The method according to claim 1, characterized in that: Before the first client device sends the binding relationship information to the server device, the method further includes: The first client device receives first information sent by the second client device, where the first information is used to determine the binding relationship information; The first information is used to indicate the identity of the second client device and related information of the first root certificate.

3. The method according to claim 2, characterized in that The first information includes one or more of the following information: a manufacturer identifier of the second client device, an application identifier of the second client device, a device identifier of the second client device, a public key of the second client device, an identity code of the second client device, and a first signature.

4. The method according to claim 2 or 3, characterized in that: The first information is provided by the second client device through out-of-band transmission.

5. The method according to any one of claims 1 to 4, characterized in that The binding relationship information is recorded in a first functional cluster, the first functional cluster includes a first attribute, and the first attribute records a corresponding relationship between a device identification of the second client device and the first root certificate.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: The first client device sends the first root certificate to the server device.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: The first client device sends an identity code of the second client device to the server device, where the identity code is used by the second client device to access the server device; The first client device receives the index of the identity code sent by the server device.

8. The method according to claim 7, characterized in that The server device includes a second functional cluster, the second functional cluster includes a second attribute, and the second attribute records the corresponding relationship between the identity code and the index of the identity code.

9. The method according to any one of claims 1 to 8, characterized in that The method further comprises: The first client device sends a first command to the server device, where the first command is used for the server device to broadcast parameters of the first command.

10. The method according to claim 9, characterized in that The parameters of the first command include one or more of the following: an index of the identity code of the second client device, a device identifier of the second client device, a manufacturer identifier of the first client device, an application identifier of the first client device, a broadcast time of the parameters of the first command, and an encryption method supported by the server device.

11. The method according to claim 9 or 10, characterized in that: The method further comprises: The first client device sends a second command to the server device, where the second command is used for the server device to broadcast parameters of the second command.

12. The method according to claim 11, characterized in that If the first command and the second command are different, the method further includes: The first client device receives a response message sent by the server device, where the response message is used to indicate that the first client device is waiting to broadcast the parameters of the second command, or the response message is used to indicate whether the first client device has finished broadcasting the parameters of the first command.

13. The method according to any one of claims 1 to 12, characterized in that The server device is a vehicle device or a vehicle-mounted terminal.

14. An access control method, characterized in that: include: The server device receives binding relationship information sent by the first client device, wherein the binding relationship information is used to indicate that a binding relationship exists between the second client device and the first root certificate, and the binding relationship is used to perform certificate chain verification when the server device and the second client device establish an operation connection channel.

15. The method according to claim 14, characterized in that The binding relationship information is determined according to first information, where the first information is used to indicate the identity of the second client device and related information of the first root certificate.

16. The method according to claim 15, characterized in that The first information includes one or more of the following information: a manufacturer identifier of the second client device, an application identifier of the second client device, a device identifier of the second client device, a public key of the second client device, an identity code of the second client device, and a first signature.

17. The method according to claim 15 or 16, characterized in that The first information is provided by the second client device through out-of-band transmission.

18. The method according to any one of claims 14 to 17, characterized in that: The binding relationship information is recorded in a first functional cluster, the first functional cluster includes a first attribute, and the first attribute records a corresponding relationship between a device identification of the second client device and the first root certificate.

19. The method according to any one of claims 14 to 18, characterized in that The method further comprises: The server device receives the first root certificate sent by the first client device.

20. The method according to any one of claims 14 to 19, characterized in that The method further comprises: The server device receives the identity code of the second client device sent by the first client device, where the identity code is used by the second client device to access the server device; The server device sends the index of the identity code to the first client device.

21. The method according to claim 20, characterized in that The server device includes a second functional cluster, the second functional cluster includes a second attribute, and the second attribute records the corresponding relationship between the identity code and the index of the identity code.

22. The method according to any one of claims 14 to 21, characterized in that The method further comprises: The server device receives a first command, where the first command is used for the server device to broadcast parameters of the first command; The server device broadcasts the parameters of the first command.

23. The method according to claim 22, characterized in that The parameters of the first command include one or more of the following: an index of the identity code of the second client device, a device identifier of the second client device, a manufacturer identifier of the first client device, an application identifier of the first client device, a broadcast time of the parameters of the first command, and an encryption method supported by the server device.

24. The method according to claim 22 or 23, characterized in that The method further comprises: The server device receives a second command, where the second command is used for the server device to broadcast parameters of the second command.

25. The method according to claim 24, characterized in that The method further comprises: If the initiator of the first command and the second command is the same, the server device merges the parameters of the first command and the parameters of the second command, and broadcasts the parameters of the merged command.

26. The method according to claim 24, characterized in that The method further comprises: The server device broadcasts the parameters of the first command and the parameters of the second command in turn.

27. The method according to claim 24, characterized in that The method further comprises: If the first command and the second command are different, the server device sends a response message to the initiator of the second command, and the response message is used to indicate that the initiator of the second command waits for broadcasting the parameters of the second command, or the response message is used to indicate whether the initiator of the second command ends broadcasting the parameters of the first command.

28. The method according to any one of claims 14 to 27, characterized in that The server device is a vehicle device or a vehicle-mounted terminal.

29. An access control method, characterized in that: include: The second client device sends first information to the first client device, where the first information is used to determine binding relationship information; The binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used for performing certificate chain verification when the second client device and the server device establish an operation connection channel.

30. The method according to claim 29, characterized in that The first information is used to indicate the identity of the second client device and related information of the first root certificate.

31. The method according to claim 29 or 30, characterized in that The first information includes one or more of the following information: a manufacturer identifier of the second client device, an application identifier of the second client device, a device identifier of the second client device, a public key of the second client device, an identity code of the second client device, and a first signature.

32. The method according to any one of claims 29 to 31, characterized in that The first information is provided by the second client device through out-of-band transmission.

33. The method according to any one of claims 29 to 32, characterized in that The binding relationship information is recorded in a first functional cluster, the first functional cluster includes a first attribute, and the first attribute records a corresponding relationship between a device identification of the second client device and the first root certificate.

34. The method according to any one of claims 29 to 33, characterized in that The method further comprises: The second client device receives the parameter of the first command broadcast by the server device; The second client device establishes an operation connection channel with the server device based on the parameters of the first command.

35. The method according to claim 34, characterized in that The parameters of the first command include one or more of the following: an index of the identity code of the second client device, a device identifier of the second client device, a manufacturer identifier of the first client device, an application identifier of the first client device, a broadcast time of the parameters of the first command, and an encryption method supported by the server device.

36. The method according to any one of claims 29 to 35, characterized in that The server device is a vehicle device or a vehicle-mounted terminal.

37. A client device, characterized in that: The client device is a first client device, and the first client device includes: The first sending module is used to send binding relationship information to the server device, where the binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used to perform certificate chain verification when the server device and the second client device establish an operation connection channel.

38. The client device according to claim 37, characterized in that The first client device also includes: A first receiving module, configured to receive first information sent by the second client device, wherein the first information is used to determine the binding relationship information; The first information is used to indicate the identity of the second client device and related information of the first root certificate.

39. The client device according to claim 38, characterized in that The first information includes one or more of the following information: a manufacturer identifier of the second client device, an application identifier of the second client device, a device identifier of the second client device, a public key of the second client device, an identity code of the second client device, and a first signature.

40. The client device according to claim 38 or 39, characterized in that The first information is provided by the second client device through out-of-band transmission.

41. The client device according to any one of claims 37-40, characterized in that The binding relationship information is recorded in a first functional cluster, the first functional cluster includes a first attribute, and the first attribute records a corresponding relationship between a device identification of the second client device and the first root certificate.

42. The client device according to any one of claims 37 to 41, characterized in that: The first client device also includes: The second sending module is used to send the first root certificate to the server device.

43. The client device according to any one of claims 37-42, characterized in that The first client device also includes: A third sending module, used for sending the identity code of the second client device to the server device, where the identity code is used by the second client device to access the server device; The second receiving module is used to receive the index of the identity code sent by the server device.

44. The client device according to claim 43, characterized in that The server device includes a second functional cluster, the second functional cluster includes a second attribute, and the second attribute records the corresponding relationship between the identity code and the index of the identity code.

45. The client device according to any one of claims 37-44, characterized in that The first client device also includes: The fourth sending module is used to send a first command to the server device, where the first command is used for the server device to broadcast parameters of the first command.

46. ​​The client device according to claim 45, characterized in that The parameters of the first command include one or more of the following: an index of the identity code of the second client device, a device identifier of the second client device, a manufacturer identifier of the first client device, an application identifier of the first client device, a broadcast time of the parameters of the first command, and an encryption method supported by the server device.

47. The client device according to claim 45 or 46, characterized in that The first client device also includes: A fifth sending module is used to send a second command to the server device, where the second command is used for the server device to broadcast parameters of the second command.

48. The client device according to claim 47, characterized in that The first client device also includes: The third receiving module is used to receive a response message sent by the server device if the first command and the second command are different, and the response message is used to indicate that the first client device is waiting for the parameters of the second command to be broadcast, or the response message is used to indicate whether the first client device has finished broadcasting the parameters of the first command.

49. The client device according to any one of claims 37-48, characterized in that The server device is a vehicle device or a vehicle-mounted terminal.

50. A server device, characterized in that: include: The first receiving module is used to receive binding relationship information sent by the first client device, where the binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used to perform certificate chain verification when the server device and the second client device establish an operation connection channel.

51. The server device according to claim 50, characterized in that: The binding relationship information is determined according to first information, where the first information is used to indicate the identity of the second client device and related information of the first root certificate.

52. The server device according to claim 51, characterized in that: The first information includes one or more of the following information: a manufacturer identifier of the second client device, an application identifier of the second client device, a device identifier of the second client device, a public key of the second client device, an identity code of the second client device, and a first signature.

53. The server device according to claim 51 or 52, characterized in that: The first information is provided by the second client device through out-of-band transmission.

54. The server device according to any one of claims 50-53, characterized in that: The binding relationship information is recorded in a first functional cluster, the first functional cluster includes a first attribute, and the first attribute records a corresponding relationship between a device identification of the second client device and the first root certificate.

55. The server device according to any one of claims 50-54, characterized in that: The server device also includes: The second receiving module is used to receive the first root certificate sent by the first client device.

56. The server device according to any one of claims 50-55, characterized in that: The server device also includes: A third receiving module, used to receive an identity code of the second client device sent by the first client device, where the identity code is used by the second client device to access the server device; The first sending module is used to send the index of the identity code to the first client device.

57. The server device according to claim 56, characterized in that: The server device includes a second functional cluster, the second functional cluster includes a second attribute, and the second attribute records the corresponding relationship between the identity code and the index of the identity code.

58. The server device according to any one of claims 50-57, characterized in that: The server device also includes: a fourth receiving module, configured to receive a first command, wherein the first command is used for the server device to broadcast parameters of the first command; The first broadcast module is used to broadcast the parameters of the first command.

59. The server device according to claim 58, characterized in that: The parameters of the first command include one or more of the following: an index of the identity code of the second client device, a device identifier of the second client device, a manufacturer identifier of the first client device, an application identifier of the first client device, a broadcast time of the parameters of the first command, and an encryption method supported by the server device.

60. The server device according to claim 58 or 59, characterized in that: The server device also includes: The fifth receiving module is used to receive a second command, where the second command is used for the server device to broadcast parameters of the second command.

61. The server device according to claim 60, characterized in that: The server device also includes: The merging and broadcasting module is used to merge the parameters of the first command and the parameters of the second command if the initiators of the first command and the second command are the same, and broadcast the parameters of the merged command.

62. The server device according to claim 60, characterized in that: The server device also includes: The second broadcast module is used to broadcast the parameters of the first command and the parameters of the second command in turn.

63. The server device according to claim 60, characterized in that: The server device also includes: A second sending module is used to send a response message to the initiator of the second command if the first command and the second command are different, and the response message is used to indicate that the initiator of the second command is waiting to broadcast the parameters of the second command, or the response message is used to indicate whether the initiator of the second command has finished broadcasting the parameters of the first command.

64. The server device according to any one of claims 50-63, characterized in that: The server device is a vehicle device or a vehicle-mounted terminal.

65. A client device, characterized in that: The client device is a second client device, and the second client device includes: A sending module, configured to send first information to a first client device, wherein the first information is used to determine binding relationship information; The binding relationship information is used to indicate that there is a binding relationship between the second client device and the first root certificate, and the binding relationship is used for performing certificate chain verification when the second client device and the server device establish an operation connection channel.

66. The client device according to claim 65, characterized in that The first information is used to indicate the identity of the second client device and related information of the first root certificate.

67. The client device according to claim 65 or 66, characterized in that The first information includes one or more of the following information: a manufacturer identifier of the second client device, an application identifier of the second client device, a device identifier of the second client device, a public key of the second client device, an identity code of the second client device, and a first signature.

68. The client device according to any one of claims 65-67, characterized in that The first information is provided by the second client device through out-of-band transmission.

69. The client device according to any one of claims 65-68, characterized in that The binding relationship information is recorded in a first functional cluster, the first functional cluster includes a first attribute, and the first attribute records a corresponding relationship between a device identification of the second client device and the first root certificate.

70. The client device according to any one of claims 65-69, characterized in that The second client device further includes: A receiving module, used for receiving the parameters of the first command broadcast by the server device; An establishing module is used to establish an operation connection channel with the server device based on the parameters of the first command.

71. The client device according to claim 70, characterized in that The parameters of the first command include one or more of the following: an index of the identity code of the second client device, a device identifier of the second client device, a manufacturer identifier of the first client device, an application identifier of the first client device, a broadcast time of the parameters of the first command, and an encryption method supported by the server device.

72. The client device according to any one of claims 65-71, characterized in that The server device is a vehicle device or a vehicle-mounted terminal.

73. A client device, characterized in that It comprises a memory and a processor, wherein the memory is used to store a program, and the processor is used to call the program in the memory so that the client device executes the method as described in any one of claims 1-13 and 29-36.

74. A server device, characterized in that: It includes a memory and a processor, the memory is used to store programs, and the processor is used to call the programs in the memory so that the server device executes the method as described in any one of claims 14-28.

75. A device, characterized in that It comprises a processor, which is used to call a program from a memory so that the device executes the method as described in any one of claims 1-36.

76. A chip, characterized in that: It comprises a processor, which is used to call a program from a memory, so that a device equipped with the chip executes a method as described in any one of claims 1 to 36.

77. A computer-readable storage medium, characterized in that A program is stored thereon, the program causing a computer to execute the method according to any one of claims 1 to 36.

78. A computer program product, characterized in that The method comprises a program which causes a computer to execute the method according to any one of claims 1 to 36.

79. A computer program, characterized in that The computer program enables a computer to execute the method according to any one of claims 1 to 36.

Images