Method and Device for Using Access Token

Abstract

This application relates to a method and device for using access tokens. Among them, a method for using access tokens includes: a first device performing a first operation using at least one level of access token. In the embodiments of this application, different levels of access tokens can be used to control access permissions with finer granularity, which is beneficial to improving security.

Description

Technical Field

[0001] The present application relates to the field of communications, and more specifically, to a method and device for using an access token. Background Art

[0002] The Open Link Alliance (OLA) specifications for smart home devices do not yet specify access control permissions and methods for application terminals. Users can issue access tokens to devices through mobile apps or cloud platforms, or devices can proactively request access tokens from the cloud platform, allowing devices under a user's account to access each other. The cloud platform can also be referred to as the cloud or access cloud. However, current access tokens cannot achieve more granular access control. Summary of the Invention

[0003] The embodiments of the present application provide a method and device for using an access token, which can control access rights at a more fine-grained level.

[0004] An embodiment of the present application provides a method for using an access token, including: a first device uses at least one level of access token to perform a first operation.

[0005] An embodiment of the present application provides a first device, including: a control unit, configured to perform a first operation using at least one level of access token.

[0006] An embodiment of the present application provides a first device, comprising a processor and a memory, wherein the memory is configured to store a computer program, and the processor is configured to call and execute the computer program stored in the memory, so that the first device executes the above-mentioned access token usage method.

[0007] An embodiment of the present application provides a chip for implementing the above-mentioned method for using an access token.

[0008] Specifically, the chip includes: a processor, configured to call and run a computer program from a memory, so that a device equipped with the chip executes the above-mentioned method for using an access token.

[0009] An embodiment of the present application provides a computer-readable storage medium for storing a computer program. When the computer program is executed by a device, the device executes the above-mentioned access token usage method.

[0010] An embodiment of the present application provides a computer program product, including computer program instructions, which enable a computer to execute the above-mentioned access token usage method.

[0011] An embodiment of the present application provides a computer program, which, when executed on a computer, enables the computer to execute the above-mentioned method for using an access token.

[0012] In the embodiments of the present application, different levels of access tokens can be used to control access permissions with finer granularity, which is beneficial to improving security. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a schematic diagram of the device model of OLA according to an embodiment of the present application.

[0014] Figure 2 is a flowchart of an example of issuing an access token.

[0015] Figure 3 is a schematic flowchart of a method for using an access token according to an embodiment of the present application.

[0016] Figure 4 is a schematic flowchart of a method for using an access token according to another embodiment of the present application.

[0017] Figure 5 is a schematic flowchart of a method for using an access token according to another embodiment of the present application.

[0018] Figure 6 is a flowchart of Example 8 in the method for using an access token according to another embodiment of the present application.

[0019] Figure 7 is a flowchart of Example 9 in the method for using an access token according to another embodiment of the present application.

[0020] Figure 8 is a flowchart of Example 10 in the method for using an access token according to another embodiment of the present application.

[0021] Figure 9 is a flowchart of Example 11 in the method for using an access token according to another embodiment of the present application.

[0022] Figure 10 is a schematic block diagram of a first device according to an embodiment of the present application.

[0023] Figure 11 is a schematic block diagram of a first device according to another embodiment of the present application.

[0024] Figure 12 is a schematic block diagram of a first device according to another embodiment of the present application.

[0025] Figure 13 is a schematic block diagram of a communication device according to an embodiment of the present application.

[0026] Figure 14 is a schematic block diagram of a chip according to an embodiment of the present application.

[0027] Figure 15It is a schematic block diagram of a communication system according to an embodiment of the present application. Detailed implementation manners

[0028] Next, the technical solutions in the embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application.

[0029] To facilitate the understanding of the technical solutions in the embodiments of the present application, the related technologies in the embodiments of the present application are described below. The following related technologies can be arbitrarily combined with the technical solutions in the embodiments of the present application as optional solutions, and all of them fall within the protection scope of the embodiments of the present application.

[0030] Regarding the device model of the Open Link Alliance (OLA):

[0031] According to the draft specification of the smart home OLA, the device model of OLA can be referred to Figure 1 . Among them, the device can include various application terminals, such as smart home devices in the smart home scenario, etc. The application terminal can describe its function set through different service sets. The service can be an independent and meaningful function group, and the service can include attributes, methods, events, etc. Among them, the attribute can be the smallest unit for describing the state and function of the application terminal. The method can be used to implement the specific function of the service, and this kind of function generally cannot be completed by reading and writing a single attribute. The event can include specific information actively reported by the application terminal to other devices.

[0032] For example, the device can include the following fields:

[0033] type: The device type, which can include the device name, the unique identifier of the device type (deviceUUID), etc.;

[0034] description: The description of the device, used to explain the function of the device, etc.;

[0035] serviceList: The service list, where each service can identify the service type and whether it is mandatory in this device.

[0036] For another example, the service can include the following fields:

[0037] type: The service type, which can include the service name, the unique identifier of the service type (ServiceUUID), etc.;

[0038] description: The description of the service, used to explain the purpose of the service, etc.;

[0039] actionList: List of methods, where each method can include the method type and whether it is mandatory in this service;

[0040] eventList: List of events, where each event can include the event type and whether it is mandatory in this service;

[0041] propertyList: List of properties, where each property can include the property type and whether it is mandatory in this service.

[0042] For another example, a property can include the following fields:

[0043] type: Property type, which can include property name (name), unique identifier of the property type (propertyUUID), etc.;

[0044] dataType: Data type of the property value, such as integer, string, structure, etc.;

[0045] access: Access permission of the property, for example: read (R), write (W), notify (N), and any combination of the three. Generally, properties that support the notify (N) permission need to support the read (R) permission; properties that only support the write (W) permission and do not support the read (R) permission should not support the notify (N) permission;

[0046] For another example, a method (action) can include the following fields:

[0047] type: Method type, which can include operation name (name), unique identifier of the operation type (actionUUID), etc.;

[0048] description: Description of the operation, used to explain the purpose of the operation or usage rules, etc.;

[0049] inParameter: List of input parameters, which can be 0 or more;

[0050] outParameter: List of output parameters, which can be 0 or more.

[0051] For another example, an event can include the following fields:

[0052] type: Event type, which can include event name (name), unique identifier of the event (eventUUID), etc.; for example, event types can include, for example: message (general message, such as device online / offline), alert (alarm message, such as refrigerator door not closed), and fault (device fault message, such as compressor not working), etc.;

[0053] outParameter: zero or more parameters that may be included in the reported event message; the above attributes should support notification.

[0054] description: A description of the event, used to explain the purpose of the event or usage rules, etc.

[0055] Regarding the access token (Token):

[0056] The user issues an access token to the device through the mobile application or through the cloud platform, or the device actively requests an access token from the cloud platform, enabling the devices under the user's account to access each other. Among them, the cloud platform can also be referred to as the cloud, access cloud, etc. See Figure 2 , and an example of the process of issuing a token for access is as follows:

[0057] (1) An example of the process of issuing an access token to the device through the cloud may include:

[0058] S11 and S12. Configure the device to access the network. For example, the user configures an IoT (Internet of Things) device to access the network through the mobile application.

[0059] S13. The device accesses the network for the first time.

[0060] S14. If there is no account-level access token in the access cloud, an account-level token can be generated and saved; if there is an account-level token in the access cloud, directly execute S15 to issue the account-level token to the device. Generally speaking, when the device accesses the network for the first time, there is no account-level token in the access cloud, and when the device accesses the network again, there may be an access token in the access cloud.

[0061] S15. The access cloud issues the account-level token to the device.

[0062] (2) An example of the process of issuing an access token to the device through the mobile phone may include:

[0063] S21. The mobile application requests an account-level token from the access cloud.

[0064] S22. If there is no account-level token in the access cloud, an account-level token can be generated and saved, and if there is an account-level token in the access cloud, directly execute S23 to issue the account-level token to the mobile application.

[0065] S23. The access cloud issues the account-level token to the mobile application.

[0066] S24. The mobile application issues the account-level token to the device.

[0067] (3) An example of the process in which the device actively requests an access token may include.

[0068] S31. The IoT device detects whether it has an account-level token. If not, it executes S32 to request the access cloud.

[0069] S32. The IoT device requests the access cloud to obtain an account-level token.

[0070] S33. If there is no account-level token in the access cloud, an account-level token can be generated and saved. If there is an account-level token in the access cloud, S34 can be directly executed to issue the account-level token to the device.

[0071] S34. The access cloud issues the account-level token to the device.

[0072] In this example, there is only account-level access control in the access token (Token), and the granularity of access permission control is not fine enough to flexibly perform more fine-grained access control on devices, services, attributes, etc.

[0073] Figure 3 It is a schematic flowchart of a method 300 for using an access token according to an embodiment of the present application. This method can optionally be applied to Figure 1 the device model shown, but is not limited thereto. This method includes at least some of the following content.

[0074] S310. The first device performs a first operation using at least one level of access token.

[0075] In an embodiment of the present application, when the first device performs a first operation using at least one level of access token, it can obtain the access permission of the access token used.

[0076] Optionally, in an embodiment of the present application, the at least one level of access token includes at least one of the following:

[0077] An account-level access token;

[0078] A device-level access token;

[0079] A service-level access token;

[0080] An attribute-level access token.

[0081] In an embodiment of the present application, the account-level access token can control the account-level access permission, the device-level access token can control the device-level access permission, the service-level access token can control the service-level access permission; the attribute-level access token can control the attribute-level access permission, and the control granularity is finer, which is beneficial to flexibly perform access control on devices, services, attributes, etc.

[0082] Optionally, in the embodiments of the present application, the account-level access token is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of the devices under the same account.

[0083] Exemplarily, the scope of permissions of the account-level access token may include allowing access to at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of the unrestricted services of all devices under a certain account. In the embodiments of the present application, allowing access to unrestricted attributes may include allowing operations such as reading, writing, adding, deleting, and modifying the unrestricted attributes.

[0084] In an example of a specific scope of permissions, there are device A and device B under a certain account. Device A has restricted services S1, S2 and unrestricted service S3, where S1 has unrestricted attributes C1, C2 and restricted event E0, S2 has restricted attribute C3 and unrestricted attribute C4, and S3 has unrestricted method F1 and restricted method F2. Device B has unrestricted service S4 and restricted services S5, S6, where S4 has unrestricted attribute C5, S5 has unrestricted attribute C6 and unrestricted event E1, and S6 has unrestricted attribute C7, restricted attribute C8 and restricted method F3.

[0085] If the scope of permissions of the account-level access token of this account can include allowing access to the unrestricted method F1 of the unrestricted service S3 of device A, and the unrestricted attribute C5 of the unrestricted service S4 of device B. In addition, if C5 supports read and write permissions, the scope of permissions of the account-level access token may also include allowing read and write operations on this C5.

[0086] Optionally, in the embodiments of the present application, the device-level access token is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of the unrestricted services of the same device or multiple devices under the same account.

[0087] Exemplarily, the scope of permissions of the device-level access token may include allowing access to at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device. If all devices under a certain account use the same device-level access token, the scope of permissions of the device-level access token is equivalent to the scope of permissions of the account-level access token. Referring to the above example of the scope of permissions, in a specific example, the scope of permissions of the device-level access token for device A may include allowing access to the unrestricted method F1 of the unrestricted service S3 of device A. The scope of permissions of the device-level access token for device B may include allowing access to the unrestricted attribute C5 of the unrestricted service S4 of device B.

[0088] Optionally, in the embodiments of the present application, the service-level access token includes:

[0089] Service-level access tokens for the same device;

[0090] Service-level access tokens across devices.

[0091] Exemplarily, the scope of permissions of the service-level access token may include all non-restricted attributes of one or more restricted services that allow access to one or more specified devices.

[0092] Optionally, in the embodiments of the present application, the service-level access token for the same device is used to access at least one of the non-restricted attributes, non-restricted methods, and non-restricted events of at least one restricted service of the same device;

[0093] The service-level access token across devices is used to access at least one of the non-restricted attributes, non-restricted methods, and non-restricted events of at least one restricted service of multiple devices.

[0094] In a specific example, the scope of permissions of the service-level access token for the same device may include: allowing access to the non-restricted attributes C1 and C2 of the restricted service S1 of device A.

[0095] In a specific example, the scope of permissions of the service-level access token across devices may include: allowing access to the non-restricted attributes C1 and C2 of the restricted service S1 of device A, and the non-restricted attribute C7 of the restricted service S6 of device B.

[0096] Optionally, in the embodiments of the present application, the attribute-level access token includes:

[0097] Attribute-level access tokens for the same service;

[0098] Attribute-level access tokens across services;

[0099] Attribute-level access tokens across devices.

[0100] Exemplarily, the scope of permissions of the attribute-level access token may include allowing access to one or more restricted attributes, restricted methods, or restricted events of one or more restricted services of one or more specified devices. The scope of permissions of the attribute-level access token may also include allowing access to one or more restricted attributes, restricted methods, or restricted events of one or more non-restricted services of one or more specified devices.

[0101] Optionally, in the embodiments of the present application, the attribute-level access token for the same service is used to access at least one of the at least one restricted attribute, restricted method, and restricted event of the same service of the same device;

[0102] An attribute-level access token across services is used to access at least one of at least one restricted attribute, restricted method, and restricted event of multiple services of the same device;

[0103] An attribute-level access token across devices is used to access at least one of at least one restricted attribute, restricted method, and restricted event of multiple services of multiple devices.

[0104] The same service mentioned above can be the same restricted service or the same unrestricted service.

[0105] The multiple services mentioned above can include multiple restricted services, can include multiple unrestricted services, or can include both restricted services and unrestricted services.

[0106] In a specific example, the permission scope of an attribute-level access token of the same service can include: allowing access to the restricted attribute C3 of the restricted service S2 of device A.

[0107] In a specific example, the permission scope of an attribute-level access token of the same service can include: allowing access to the restricted method F2 of the unrestricted service S3 of device A.

[0108] In a specific example, the permission scope of an attribute-level access token across services can include: allowing access to the restricted event E0 of the restricted service S1 of device A, and the restricted attribute C3 of the restricted service S2.

[0109] In a specific example, the permission scope of an attribute-level access token across services can include: allowing access to the restricted event E0 of the restricted service S1 of device A, and the restricted method F2 of the unrestricted service S3.

[0110] In a specific example, the permission scope of an attribute-level access token across devices can include: allowing access to the restricted attribute C3 of the restricted service S2 of device A, and the restricted attribute C8 and restricted method F3 of the restricted service S6 of device B.

[0111] In a specific example, the permission scope of an attribute-level access token across devices can include: allowing access to the restricted method F2 of the unrestricted service S3 of device A, and the restricted attribute C8 and restricted method F3 of the restricted service S6 of device B.

[0112] Optionally, in the embodiments of the present application, the first operation includes at least one of the following:

[0113] Establish a secure session;

[0114] Perform a login verification;

[0115] Encrypt and decrypt communication messages.

[0116] In the embodiments of the present application, during the process of establishing a secure session, performing login verification, and encrypting and decrypting communication messages, various levels of access tokens can be flexibly used based on specific requirements.

[0117] For example, the first device uses one or more levels of access tokens to establish a secure session with the second device.

[0118] For another example, the first device uses one or more levels of access tokens to perform login verification with the second device.

[0119] For another example, the first device and the second device use one or more levels of access tokens to encrypt and decrypt communication messages, and verify whether the data to be accessed by the communication messages is within the access scope of the access token.

[0120] For another example, different levels of access tokens, different access tokens of the same level, or the same access token are respectively used during the process of establishing a secure session and performing login verification.

[0121] For another example, different levels of access tokens, different access tokens of the same level, or the same access token are respectively used during the process of establishing a secure session and encrypting / decrypting messages.

[0122] For another example, different levels of access tokens, different access tokens of the same level, or the same access token are respectively used during the process of performing login verification and encrypting / decrypting messages.

[0123] For another example, different levels of access tokens, different access tokens of the same level, or the same access token are respectively used during the process of establishing a secure session, performing login verification, and encrypting / decrypting messages.

[0124] Optionally, in the embodiments of the present application, a session may include a connection, and a secure session may include a secure connection. Establishing a secure session between the first device and the second device may include: establishing a secure connection between the first device and the second device.

[0125] Optionally, in the embodiments of the present application, the method for establishing a secure session includes at least one of the following:

[0126] Using an account-level access token as a Pre-Shared Key (PSK) to establish a secure session with the second device;

[0127] Using a device-level access token as a PSK to establish a secure session with the second device;

[0128] Using a service-level access token as a PSK to establish a secure session with the second device;

[0129] Using an attribute-level access token as a PSK to establish a secure session with the second device.

[0130] Exemplarily, based on different requirements, the first device may select at least one of an account-level access token, a device-level access token, a service-level access token, and an attribute-level access token as the PSK to establish a secure session with the second device. Multiple sessions with the same and / or different access permissions are allowed, and the access permissions on multiple sessions are independent of each other.

[0131] Optionally, in the embodiments of the present application, the secure session includes at least one of the following:

[0132] Transport Layer Security (TLS) session;

[0133] Datagram Transport Layer Security (DTLS) session;

[0134] Application layer secure session.

[0135] For example, the application layer secure session may include an Object Security for Constrained RESTful Environments (OSCORE) protocol (see RFC 8613) secure session for a restricted RESTful environment, or other custom protocol secure sessions. Among them, RESTful is a resource-oriented architecture that conforms to the Representational state transfer (REST) specification.

[0136] Optionally, in the embodiments of the present application, the methods for performing login verification include at least one of the following:

[0137] Use the account-level access token as the verification key to perform login verification with the second device;

[0138] Use the device-level access token as the verification key to perform login verification with the second device;

[0139] Use the service-level access token as the verification key to perform login verification with the second device;

[0140] Use the attribute-level access token as the verification key to perform login verification with the second device.

[0141] Optionally, in the embodiments of the present application, the algorithm for the login verification is symmetric encryption, and the verification keys used by the first device for login and the second device for verification are the same.

[0142] Optionally, in the embodiments of the present application, the algorithm for login verification is asymmetric encryption. The verification key includes a public key and a private key corresponding to the public key. The first device uses the public key for login, and the second device uses the private key corresponding to the public key for verification.

[0143] During the login verification process, either a symmetric encryption algorithm or an asymmetric algorithm can be used. If a symmetric algorithm is used, the values of the access tokens used by the first device for login and the second device for verification can be the same. If an asymmetric algorithm is used, the value of the access token can include a pair of keys, where the controlling party holds the public key and the controlled party holds the private key. For example, the first device uses the public key as the verification key for login, and the second device uses the private key corresponding to the public key as the verification key for verification.

[0144] Optionally, in the embodiments of the present application, the situations where device-level access tokens are used include:

[0145] Needing to access a second device in a specific group.

[0146] Optionally, in the embodiments of the present application, the situations where service-level access tokens are used include:

[0147] Needing to access restricted services of the second device.

[0148] Optionally, in the embodiments of the present application, the situations where attribute-level access tokens are used include:

[0149] Needing to access at least one of the restricted attributes, restricted methods, and restricted events of the second device.

[0150] Optionally, in the embodiments of the present application, needing to access the restricted attributes of the second device includes needing to perform at least one of the following operations on the restricted attributes of the second device:

[0151] Read, write, add, delete, and modify.

[0152] Exemplarily, based on different requirements, it is possible to select which level of access token to use to establish a secure session. Specifically, for example: when needing to access a certain account or by default, use an account-level access token to establish a secure session with the second device. When needing to access a second device in a specific group, use a device-level access token to establish a secure session with the second device. When needing to access restricted services of the second device, use a service-level access token to establish a secure session with the second device. When needing to access at least one of the restricted attributes, restricted methods, and restricted events of the second device, use an attribute-level access token to establish a secure session with the second device.

[0153] Exemplarily, based on different requirements, it is possible to select which level of access token to use for login verification. Specifically, for example: when accessing a certain account or by default, use the account-level access token as the verification key to perform login verification with the second device. When accessing a second device in a specific group, use the device-level access token as the verification key to perform login verification with the second device. When accessing a restricted service of the second device, use the service-level access token as the verification key to perform login verification with the second device. When accessing at least one of the restricted attributes, restricted methods, and restricted events of the second device, use the attribute-level access token as the verification key to perform login verification with the second device.

[0154] Optionally, in the embodiments of the present application, the access permissions of multiple access tokens are stackable in the same session.

[0155] Optionally, in the embodiments of the present application, the access permissions of multiple access tokens are overridable in the same session.

[0156] Optionally, in the embodiments of the present application, the access permissions of multiple access tokens are independent of each other in different sessions.

[0157] Exemplarily, the first device can establish multiple secure sessions with the second device by using multiple levels of access tokens. In different secure sessions, the permission scopes of multiple levels of access tokens can be independent of each other. In the same session, the permission scopes of multiple levels of access tokens can be stackable or overridable.

[0158] For example, in the same session, the access permission of the account-level access token includes allowing access to the non-restricted method F1 of the non-restricted service S3 of device A; the access permission of the device-level access token includes allowing access to the non-restricted attribute C1 of the restricted service S1 of device A. Stacking the permission scopes of these two access tokens, the access permission in this session includes allowing access to the non-restricted method F1 of the non-restricted service S3 of device A and allowing access to the non-restricted attribute C1 of the restricted service S1 of device A.

[0159] For another example, in the same session, the access permission of the account-level access token includes allowing access to the non-restricted method F1 of the non-restricted service S3 of device A; the access permission of the device-level access token includes allowing access to the non-restricted attribute C1 of the restricted service S1 of device A. Overriding the account-level access token with the device-level access token, the access permission in this session includes allowing access to the non-restricted attribute C1 of the restricted service S1 of device A.

[0160] In the embodiments of the present application, different levels of access tokens can be used to control access permissions with finer granularity, which is beneficial to improving security. For example, during the establishment of a secure session, at least one level of secure session at the account level, device level, service level, and attribute level can be established, which is beneficial to improving session security. Another example is that during the login verification process, at least one level of verification key at the account level, device level, service level, and attribute level can be used for login verification, which is beneficial to improving login security. Another example is that during the process of encrypting and decrypting communication messages, at least one level of communication key at the account level, device level, service level, and attribute level can be used to encrypt and decrypt the messages, which is beneficial to improving the security of message transmission.

[0161] Figure 4 FIG. 400 is a schematic flowchart of a method for using an access token according to an embodiment of the present application. Optionally, this method can be applied to Figure 1 the device model shown, but is not limited thereto. This method may include some or all of the content of method 300. This method 400 may also include at least some of the following content.

[0162] Optionally, in the first mode of the embodiments of the present application, the first device may be the master device, and the second device may be the controlled device. The first device may be the sender of the first message, and the second device may be the receiver of the first message. The first message sent by the first device to the second device may be a control message or a request message. Also, the second device may be the sender of the second message, and the first device may be the receiver of the second message. The second message received by the first device from the second device may be a response message (also referred to as a result message) to the first message.

[0163] Optionally, in the first mode of the embodiments of the present application, as Figure 4 shown, the method for encrypting and decrypting communication messages includes:

[0164] S410. The first device sends a first message, which includes an identifier of a communication key, and the communication key is obtained based on at least one level of access token.

[0165] Optionally, in the first mode of the embodiments of the present application, the communication key is at least one level of access token; or

[0166] the communication key is a key obtained by encrypting at least one level of access token using a first algorithm.

[0167] For example, a certain access token (token) value can be directly used as the communication key.

[0168] For another example, a communication key can be obtained by encrypting a certain token value using a predefined encryption algorithm. Among them, the predefined encryption algorithm can include multiple types, such as Hash-based Message Authentication Code (HMAC), HMAC-based Key Derivation Function (HKDF), Password-Based Key Derivation Function (PBKDF), etc.

[0169] Optionally, in the first method of the embodiments of the present application, the first device sending the first message includes at least one of the following:

[0170] The first device sends the first message to the second device;

[0171] The first device sends the first message to the first cloud, and the first cloud forwards the first message to the second device;

[0172] The first device sends the first message to the second cloud through the first cloud, and the second cloud forwards the first message to the second device;

[0173] The first device sends the first message to the first cloud, and the first cloud decrypts and verifies the first message using a second algorithm and the communication key, and then forwards the verified first message to the second device;

[0174] The first device sends the first message to the second cloud through the first cloud, and the second cloud decrypts and verifies the first message using a second algorithm and the communication key, and then forwards the verified first message to the second device.

[0175] In the embodiments of the present application, the first device can directly send the first message to the second device, or send the first message to the second device through one or more clouds (or referred to as cloud platforms, cloud devices, access clouds, etc.).

[0176] For example, the first device and the second device are connected to the same first cloud. The first device sends the first message to the first cloud, and the first cloud forwards it to the second device. In addition, after receiving the first message, the first cloud can first decrypt and verify the first message using a predefined second algorithm and the communication key. If the decryption and verification are passed, the first cloud then forwards the first message to the second device. If the decryption and verification fail, the first cloud may not forward the first message.

[0177] For another example, the first device is connected to the first cloud, and the second device is connected to the second cloud. The first device can send a first message to the first cloud, which forwards it to the second cloud, and then the second cloud forwards it to the second device. In addition, after receiving the first message, the first cloud can first decrypt and verify the first message using a predefined second algorithm and a communication key. If the decryption and verification are successful, the first cloud forwards the first message to the second cloud and then to the second device. If the decryption and verification fail, the first cloud may not forward the first message.

[0178] In this way, some messages can be intercepted by the cloud, reducing the waste of transmission resources.

[0179] In the embodiments of the present application, the predefined second algorithm for encrypting and decrypting the first message may employ AEAD series algorithms, such as AEAD_AES_128_CCM, see RFC 5116 "5. AEAD Algorithms" and RFC 8446 "5.2. Record Payload Protection". The second algorithm may also employ AES series algorithms, such as AES_256_CCM, see NIST FIPS PUB 197.

[0180] Optionally, in the first mode of the embodiments of the present application, the method further includes:

[0181] S420. The first device receives a second message, where the second message is a response message to the first message;

[0182] Wherein, the second message is a plaintext message or an encrypted message;

[0183] In the case where the second message is an encrypted message, the second message includes an identifier of the communication key.

[0184] Optionally, the response message generated by the receiving party can be returned in plaintext or encrypted using the same token and method as the request message. Therefore, the second message can be a plaintext message or an encrypted message. When the second message is an encrypted message, it is necessary to include the identifier of the communication key.

[0185] Optionally, in the first mode of the embodiments of the present application, the first device receiving the second message includes at least one of the following:

[0186] The first device receives the second message from the second device;

[0187] The first device receives the second message from the first cloud, where the second message is a message received by the first cloud from the second device;

[0188] The first device receives the second message from the second cloud via the first cloud, where the second message is the message received by the second cloud from the second device;

[0189] The first device receives the second message from the first cloud, where the second message is the message received by the first cloud from the second device and decrypted and verified through the second algorithm and the communication key;

[0190] The first device receives the second message from the second cloud via the first cloud, where the second message is the message received by the second cloud from the second device and decrypted and verified through the second algorithm and the communication key.

[0191] In the embodiments of the present application, the first device may directly receive the second message from the second device, or may receive the second message from the second device through one or more clouds (or referred to as cloud platforms, cloud devices, access clouds, etc.).

[0192] For example, the first device and the second device are connected to the same first cloud. The second device may send the second message to the first cloud, and the first cloud forwards it to the first device. In addition, if the second message is an encrypted message, after receiving the second message, the first cloud may first decrypt and verify the second message using a predefined second algorithm and a communication key. If the decryption and verification are passed, the first cloud then forwards the second message to the first device. If the decryption and verification fail, the first cloud may not forward the second message.

[0193] Another example is that the first device is connected to the first cloud and the second device is connected to the second cloud. The second device may send the second message to the second cloud, which forwards it to the first cloud, and then the first cloud forwards it to the first device. In addition, if the second message is an encrypted message, after receiving the second message, the second cloud may first decrypt and verify the second message using a predefined second algorithm and a communication key. If the decryption and verification are passed, the second cloud then forwards the second message to the first device. If the decryption and verification fail, the second cloud may not forward the second message.

[0194] In this way, some messages can be intercepted through the cloud, reducing the waste of transmission resources.

[0195] In the embodiments of the present application, the predefined second algorithm for encrypting and decrypting the second message may be the same as or different from the predefined second algorithm for encrypting and decrypting the first message.

[0196] Figure 5 It is a schematic flowchart of a method 500 for using an access token according to an embodiment of the present application. This method may optionally be applied to Figure 1The device model shown, but not limited thereto. The method may include some or all of the content of method 300. The method 500 may also include at least some of the following content.

[0197] Optionally, in the second mode of the embodiments of the present application, the second device may be the master device, and the first device may be the controlled device. The second device may be the sender of the first message, and the first device may be the receiver of the first message. The first message received by the first device from the second device may be a control message or a request message. Also, the first device may be the sender of the second message, and the second device may be the receiver of the second message. The second message sent by the first device to the second device may be a response message (also referred to as a result message) of the first message.

[0198] Optionally, in the second mode of the embodiments of the present application, the method of encrypting and decrypting communication messages includes:

[0199] S510. The first device receives a first message, which includes an identifier of a communication key, and the communication key is obtained based on at least one level of access token;

[0200] S520. The first device obtains at least one level of access token by using the identifier of the communication key;

[0201] S530. The first device decrypts and verifies the first message by using the obtained at least one level of access token.

[0202] Optionally, in the second mode of the embodiments of the present application, the communication key is at least one level of access token; or

[0203] The communication key is a key obtained by encrypting at least one level of access token by using a first algorithm.

[0204] For example, a certain access token (token) value can be directly used as the communication key.

[0205] Again, for example, after encrypting a certain token value by using a predefined encryption algorithm, the communication key can be obtained. Among them, the predefined encryption algorithm can include various types, such as HMAC, HKDF, PBKDF, etc.

[0206] Optionally, in the second mode of the embodiments of the present application, the first device receiving the first message includes at least one of the following:

[0207] The first device receives the first message from the second device;

[0208] The first device receives the first message from the first cloud, and the first message is a message received by the first cloud from the second device;

[0209] The first device receives the first message from the second cloud via the first cloud, and the first message is the message received by the second cloud from the second device.

[0210] The first device receives the first message from the first cloud, and the first message is the message received by the first cloud from the second device and decrypted and verified through using a second algorithm and a communication key.

[0211] The first device receives the first message from the second cloud via the first cloud, and the first message is the message received by the second cloud from the second device and decrypted and verified through using a second algorithm and a communication key.

[0212] In the embodiment of the present application, the first device may directly receive the first message from the second device, or may receive the first message from the second device through one or more clouds (or referred to as cloud platforms, cloud devices, access clouds, etc.).

[0213] For example, the first device and the second device are connected to the same first cloud. The second device may send the first message to the first cloud, and the first cloud forwards it to the first device. In addition, after receiving the first message, the first cloud may first decrypt and verify the first message by using a predefined second algorithm and a communication key. If the decryption and verification are passed, the first cloud then forwards the first message to the first device. If the decryption and verification fail, the first cloud may not forward the first message.

[0214] For another example, the first device is connected to the first cloud, and the second device is connected to the second cloud. The second device may send the first message to the second cloud, which forwards it to the first cloud, and then the first cloud forwards it to the first device. In addition, after receiving the first message, the second cloud may first decrypt and verify the first message by using a predefined second algorithm and a communication key. If the decryption and verification are passed, the second cloud then forwards the first message to the first device. If the decryption and verification fail, the second cloud may not forward the first message.

[0215] In this way, a part of the messages can be intercepted through the cloud, reducing the waste of transmission resources.

[0216] In the embodiments of the present application, the predefined second algorithm for encrypting and decrypting the first message may adopt AEAD series algorithms, such as AEAD_AES_128_CCM, see RFC 5116 "5. AEAD Algorithms" and RFC 8446 "5.2. Record Payload Protection". The second algorithm may also adopt AES series algorithms, such as AES_256_CCM, see NIST FIPS PUB 197.

[0217] Optionally, in the second method of the embodiments of the present application, the method further includes:

[0218] S540. The first device sends a second message, which is a response message to the first message, and the second message includes an identifier of the communication key.

[0219] Optionally, the response message generated by the receiving party may be returned in plaintext, or may be encrypted and returned using the same token and method as the request message. Therefore, the second message may be a plaintext message or an encrypted message. When the second message is an encrypted message, it needs to include the identifier of the communication key.

[0220] Optionally, in the second method of the embodiments of the present application, the first device sending the second message includes at least one of the following:

[0221] The first device sends the second message to the second device;

[0222] The first device sends the second message to the first cloud, and the first cloud forwards the second message to the second device;

[0223] The first device sends the second message to the second cloud through the first cloud, and the second cloud forwards the second message to the second device;

[0224] The first device sends the second message to the first cloud, and the first cloud decrypts and verifies the second message using the second algorithm and the communication key, and then forwards the verified second message to the second device;

[0225] The first device sends the second message to the second cloud through the first cloud, and the second cloud decrypts and verifies the second message using the second algorithm and the communication key, and then forwards the verified second message to the second device.

[0226] In the embodiments of the present application, the first device may directly send the second message to the second device, or may send the second message to the second device through one or more clouds (or referred to as cloud platforms, cloud devices, access clouds, etc.).

[0227] For example, a first device and a second device are connected to the same first cloud. The first device sends a second message to the first cloud, and the first cloud forwards it to the first device. Additionally, if the second message is an encrypted message, after receiving the second message, the first cloud can first decrypt and verify the second message using a predefined second algorithm and a communication key. If the decryption and verification are successful, the first cloud then forwards the second message to the second device. If the decryption and verification fail, the first cloud may not forward the second message. In this way, a part of the messages can be intercepted by the first cloud, reducing the waste of transmission resources.

[0228] Another example is that the first device is connected to the first cloud and the second device is connected to the second cloud. The first device can send the second message to the first cloud, which forwards it to the second cloud, and then the second cloud forwards it to the second device. Additionally, after receiving the second message, the first cloud can first decrypt and verify the second message using a predefined second algorithm and a communication key. If the decryption and verification are successful, the first cloud then forwards the second message to the second cloud and further to the second device. If the decryption and verification fail, the first cloud may not forward the second message. In this way, a part of the messages can be intercepted by the second cloud, reducing the waste of transmission resources.

[0229] In the embodiments of the present application, the predefined second algorithm for encrypting and decrypting the second message may be the same as or different from the predefined second algorithm for encrypting and decrypting the first message.

[0230] Optionally, in the embodiments of the present application, the algorithm for encrypting and decrypting communication messages is symmetric encryption, and the communication key used for encrypting by the sender and decrypting by the receiver of the first message is the same.

[0231] Optionally, in the embodiments of the present application, the communication key used for encrypting by the sender and decrypting by the receiver of the second message is the same.

[0232] Optionally, in the embodiments of the present application, the algorithm for encrypting and decrypting communication messages is asymmetric encryption, and the communication key includes a public key and a private key corresponding to the public key;

[0233] The first message is encrypted by the sender using the public key and decrypted by the receiver using the private key corresponding to the public key.

[0234] Optionally, in the embodiments of the present application, the second message is encrypted by the sender using the private key and decrypted by the receiver using the public key corresponding to the private key.

[0235] In the encryption and decryption process, either a symmetric encryption algorithm or an asymmetric algorithm can be used. If a symmetric algorithm is used, the values of the access tokens used by the sender to encrypt the first message and the receiver to decrypt the first message can be the same. If an asymmetric algorithm is used, the value of the access token can include a pair of keys, where the master party holds the public key and the controlled party holds the private key. For example, the sender uses the public key to encrypt the first message, and the receiver uses the private key corresponding to the public key to decrypt the first message. Another example is that the sender uses the public key to encrypt the second message, and the receiver uses the private key corresponding to the public key to decrypt the second message.

[0236] For example, if the sender of the first message is the first device, after the first device encrypts the first message using the public key, it sends it to the second device. The second device decrypts the first message using the private key corresponding to the public key. If the second device encrypts the second message using the private key and then sends the second message to the first device. The first device decrypts the second message using the public key corresponding to the private key.

[0237] For example, if the sender of the first message is the second device, after the second device encrypts the first message using the public key, it sends the first message to the first device. The first device decrypts the first message using the private key corresponding to the public key. After the first device encrypts the second message using the private key, it sends the second message to the second device. The second device decrypts the second message using the public key corresponding to the private key.

[0238] In a specific application scenario, the embodiments of the present application can provide multi-level access tokens and perform various management operations on the multi-level access tokens.

[0239] Examples of the attributes and levels of the multi-level access token (Token) are described as follows:

[0240]

[0241]

[0242] Optionally, if a device belongs to multiple accounts on the same platform at the same time, the ID of the token can adopt a combination of the account ID and the index within the account to avoid conflicts in the token indexes under different accounts.

[0243] Optionally, if a device belongs to accounts on multiple different platforms at the same time, the ID of the token can adopt a combination of the platform ID, the account ID, and the index within the account to avoid conflicts in the token indexes under different accounts.

[0244] According to the actual permission control requirements of the user, a device can be set with zero, one, or multiple device-level tokens, can be set with zero, one, or multiple service-level tokens, or can be set with zero, one, or multiple attribute-level tokens.

[0245] I. Access Token Permission Scope

[0246] 1.1 Example of Permission Scope of Multi - level Tokens:

[0247] If device A has services S1, S2, and S3, S1 has attributes C1 and C2, S2 has attributes C3 and C4, S3 has methods F1 and F2; device B has services S4, S5, and S6, S4 has attribute C5, S5 has attributes C6 and event E1, S6 has attributes C7, C8, and method F3. The default account - level token is T0. The user sets a device - level Token T1 for A, a service - level token T2 for S1, an attribute - level token T20 for E0 of S1, a service - level token T3 for S2, an attribute - level token T4 for the write permission of C3, and an attribute - level token T21 for F2 of S3. The user sets a service - level token T5 for S5 and S6 of B, and an attribute - level token T6 for C8 and F3. The following is an exemplary relationship of devices, services, attributes, etc.:

[0248] A --T1

[0249] S1 (Restricted Service) --T2

[0250] C1 (rw) (Unrestricted Attribute)

[0251] C2 (rw) (Unrestricted Attribute)

[0252] E0 (Restricted Event) --T20

[0253] S2 (Restricted Service) --T3

[0254] C3 (r) (Unrestricted Attribute)

[0255] C3 (w) (Restricted Attribute) --T4

[0256] C4 (rw) (Unrestricted Attribute)

[0257] S3 (Unrestricted Service)

[0258] F1 (Unrestricted Method)

[0259] F2 (Restricted Method) --T21

[0260] B

[0261] S4 (Unrestricted Service)

[0262] C5 (rw) (Unrestricted Attribute)

[0263] S5 (Restricted Service) -- T5

[0264] C6 (rw) (Unrestricted Attribute)

[0265] E1 (Unrestricted Event)

[0266] S6 (Restricted Service) -- T5

[0267] C7 (rw) (Unrestricted Attribute)

[0268] C8 (rw) (Restricted Attribute) -- T6

[0269] F3 (Restricted Method) -- T6

[0270] Based on the relationships among the above devices, services, and attributes, the following are examples of the permission scopes of access tokens:

[0271] (1) The permission scope of T0 can be represented in JSON (JavaScript Object Notation) as:

[0272]

[0273] (2) The permission scope of T1 can be represented in JSON as:

[0274]

[0275] (3) The permission scope of T2 can be represented in JSON as:

[0276]

[0277] (4) The permission scope of T3 can be represented in JSON as:

[0278]

[0279] (5) The permission scope of T4 can be represented in JSON as:

[0280]

[0281] (6) The permission scope of T5 can be represented in JSON as:

[0282]

[0283] (7) The permission scope of T6 can be represented in JSON as:

[0284]

[0285] (8) The permission scope of T20 can be represented in JSON as:

[0286]

[0287] (9) The permission scope of T21 can be represented in JSON as:

[0288]

[0289] 1.2 Application Examples

[0290] Application example of multi-level tokens: In the scenario where the smoke alarm is triggered to alarm after the smoke sensor detects a delay, it can be that only the alarm has the permission to read the attributes of the smoke sensor and the alarm controls itself, or it can be that another device, such as a smart speaker, acts as the master device and has the permission to access the smoke sensor device and the alarm method of accessing the alarm service of the alarm.

[0291] Application example of attributes (distinguishing read and write): If the user grants device A the permission to read attribute D in service C of device B, then the attribute-level token T1 is generated. If the user grants device A the permission to write attribute D in service C of device B, then the attribute-level token T2 is generated. If the user grants device A the permission to read and write attribute D in service C of device B, then the attribute-level tokens T1 and T2 can be generated simultaneously, or only one attribute-level token T3 can be generated.

[0292] Optionally, if the value of the attribute is a data list (array / list), the write permission of the attribute can be further split into add / delete / modify permissions. Example: If the user grants device A the permission to write attribute E (whose attribute value is a data list) in service C of device B, then the attribute-level token T4 is generated, and the permission of T4 is to be able to modify the attribute value of E arbitrarily (including adding / deleting / modifying elements in its data list). If the user grants device A the permission to add attribute E (whose attribute value is a data list) in service C of device B, then the attribute-level token T5 is generated, and the permission of T5 is to be able to add sub-elements to the attribute value of E (i.e., add elements to its data list). If the user grants device A the permission to delete attribute E (whose attribute value is a data list) in service C of device B, then the attribute-level token T6 is generated, and the permission of T6 is to be able to delete sub-elements of the attribute value of E (i.e., delete existing elements in its data list). If the user grants device A the permission to modify attribute E (whose attribute value is a data list) in service C of device B, then the attribute-level token T7 is generated, and the permission of T7 is to be able to modify sub-elements of the attribute value of E (i.e., modify existing elements in its data list). Possible usage scenarios are, for example: the fingerprint data of the door lock (the value of this attribute is a list of fingerprints), the owner's mobile phone has add / delete / modify permissions, the child's mobile phone only has the permission to view, and the guest's mobile phone only has the permission to add.

[0293] Optionally, on the device, the tokens for accessing other devices and the tokens for controlling its own access rights can be stored separately. They can also be stored together, with an identifier added to each token for differentiation.

[0294] 1.3 Expansion of Permission Scope

[0295] 1.3.1 Service-Level Tokens across Devices

[0296] Optionally, to meet the requirement of simultaneously accessing similar or related restricted services on multiple devices (e.g., turning on the switches of multiple air conditioners and setting the target temperatures of the air conditioners), the permission scope of the service-level tokens can be expanded to multiple devices instead of being limited to only one device. For example, in the aforementioned example, the user can set a service-level token T7 for S2 of device A and S4 of device B, and the permission scope of T7 can be represented in JSON as:

[0297]

[0298] 1.3.2 Attribute-Level Tokens across Services

[0299] Optionally, to meet the requirement of simultaneously accessing similar or related restricted attributes / methods / events on one device (e.g., turning on the switch of the air conditioner and setting the temperature at the same time), the permission scope of the attribute-level tokens can also be expanded to multiple services of one device instead of being limited to only one service. For example, in the aforementioned example, the user can set an attribute-level token T8 for C6 and C7 of device B, and the permission scope of T8 can be represented in JSON as:

[0300]

[0301] 1.3.3 Attribute-Level Tokens across Devices

[0302] Optionally, to meet the requirement of simultaneously accessing similar or related restricted attributes / methods / events on multiple devices (e.g., turning on the switches of multiple air conditioners, obtaining the current temperature of the temperature sensor, and setting the target temperature of the air conditioner), the permission scope of the attribute-level tokens can be further expanded to multiple devices instead of being limited to only one device. For example, in the aforementioned example, the user can set an attribute-level token T9 for C1 of device A, C6, and C7 of device B, and the permission scope of T9 can be represented in JSON as:

[0303]

[0304] Users can create tokens, update the validity period of tokens, update the scope of token permissions and update token values, delete tokens, and can also share tokens with other accounts and devices, etc.

[0305] II. Usage methods of multi-level access tokens

[0306] The device uses an access token (token) to establish at least one of a secure session with the peer device, encrypt and decrypt communication messages, and perform login verification, so as to obtain the access permissions corresponding to the used token:

[0307] 1. If Device A uses an account-level or device-level or service-level or attribute-level token to establish a secure session with peer Device B (such as a TLS / DTLS session based on PSK, or an application-layer secure session based on PSK), then Device A has the corresponding permissions (account-level or device-level or attribute-level) to access B in this session.

[0308] For example: If Device B has services S1, S2, and S3. Among them, S1 has attributes C1 and C2, S2 has attributes C3 and C4, and S3 has method F1. The default account-level token is T0. The user sets a device-level Token T1 for Device B, sets a service-level token T2 for S1, and sets an attribute-level token T3 for the write permission of C3. The relationships among devices, services, attributes, etc. in this example are as follows:

[0309]

[0310] Based on the above relationships, when Device A uses T0 to establish a session with Device B, it can read C3, read and write C4, and access F1; when Device A uses T1 to establish a session with B, it can read C3, read and write C4, and access F1; when Device A uses T2 to establish a session with Device B, it can access S1 (including reading and writing C1 and reading and writing C2); when Device A uses T3 to establish a session with Device B, it can write C3.

[0311] 2. Device A can use an account-level or device-level or service-level or attribute-level token to encrypt and decrypt communication messages. Device A can also use this token to generate a communication key using a predefined key generation algorithm such as HMAC / HKDF / PBKDF. For example, K1 = HMAC(token value, token ID), where the token value is the key, the token ID is the input data, and K1 is the generated communication key. Then use the encrypted communication key to encrypt and decrypt communication messages.

[0312] Specifically, the sender can carry the token ID in plain text in the message header. The receiver can find the corresponding token from the token list stored locally according to the token ID, or use the token to generate a communication key using a predefined key generation algorithm such as HMAC / HKDF / PBKDF, so as to decrypt the message and verify whether the data to be accessed by the message is within the permission scope of the token.

[0313] For example: If device A encrypts the communication message using T0, then device B uses T0 to decrypt and verify that the message access scope is read C3, read-write C4, and access F1. If device A encrypts the communication message using T1, then device B uses T1 to decrypt and verify that the message access scope is read C3, read-write C4, and access F1. If device A encrypts the communication message using T2, then device B uses T2 to decrypt and verify that the message access scope is access S1 (including read-write C1 and read-write C2). If device A encrypts the communication message using T3, then device B uses T3 to decrypt and verify that the message access scope is write C3.

[0314] 3. After establishing a session / secure session, device A uses an account-level or device-level or service-level or attribute-level token for login verification, so as to obtain the corresponding permissions to access B, such as account-level, device-level, service-level, or attribute-level access permissions.

[0315] The method of overriding permissions can be adopted: After logging in, obtain the corresponding access permissions of the token and automatically cancel the previous permissions. After logging in, you can log out actively, and the corresponding access permissions will be cancelled after logging out. For example: If device A uses T0 for login verification, then A can read C3, read-write C4, and access F1. If device A uses T1 for login verification again, then A can read C3, read-write C4, and access F1. If device A uses T2 for login verification again, then A can only access S1 (including read-write C1 and read-write C2). If device A uses T3 for login verification again, then A can only write C3. If device A uses T1 for login verification again, then A can read C3, read-write C4, and access F1.

[0316] It is also possible to adopt the method of superimposing permissions: After logging in, obtain the corresponding access permissions of the token. After logging in, you can log out actively. After logging out, the corresponding access permissions will be cancelled. Multiple logins with the same token are equivalent to one login. For example: If device A uses T0 for login verification, then A can read C3, read and write C4, and access F1. If device A uses T1 for login verification again, then A can read C3, read and write C4, and access F1. If device A uses T2 for login verification again, then A can read and write C1, read and write C2, read C3, read and write C4, and access F1. If device A uses T3 for login verification again, then A can read and write C1, read and write C2, read and write C3, read and write C4, and access F1. If device A logs out using T1 again, then A can read C3, read and write C4, and access F1. If device A logs out using T0 again, then A can only read and write C1, read and write C2, and write C3.

[0317] II. Multicast Usage

[0318] In scenarios where a device needs to access a peer device through multicast, it can use a multi-level access token for message encryption and decryption. Specifically, when a device needs to send a control request to multiple devices simultaneously, for example, a smart speaker sends a power-on request to multiple TVs and / or multiple air conditioners at home, it is necessary to use the token corresponding to the aforementioned permissions (or use this token to generate a communication key using a predefined key generation algorithm such as HMAC / HKDF / PBKDF) as the symmetric encryption and decryption key or the asymmetric encryption key for application layer secure communication. The ID of the token can be carried in plain text in the message header.

[0319] III. Unicast Usage

[0320] Example 1 (Multiple Sessions)

[0321] 1. By default, the device uses the account-level token as the PSK to establish a TLS / DTLS / application layer secure session with the peer device.

[0322] 2. If the device needs to access peer devices in a specific group, it is necessary to use the device-level token as the PSK to establish a TLS / DTLS / application layer secure session with the peer device.

[0323] 3. If the device needs to access the restricted services of the peer device, it is necessary to use the service-level token as the PSK to establish a TLS / DTLS / application layer secure session with the peer device.

[0324] 4. If the device needs to access the restricted attributes (distinguishing read, write, add, delete, modify) / methods / events of the peer device, it is necessary to use the attribute-level token as the PSK to establish a TLS / DTLS / application layer secure session with the peer device.

[0325] 5. Multiple sessions with the same and / or different permissions are allowed, and the access permissions on multiple sessions are independent of each other.

[0326] Example 2 (Overlaid Permissions)

[0327] 1. By default, the device uses the account-level token as the PSK to establish a TLS / DTLS / application-layer secure session with the peer device and obtains the account-level access permission.

[0328] 2. If the device needs to access the peer devices in a specific group, it needs to use the device-level token as the PSK to establish a TLS / DTLS / application-layer secure session with the peer device and obtain the device-level access permission.

[0329] 3. If the device needs to access the restricted services of the peer device, it needs to use the service-level token as the verification key to perform a login verification with the peer device on the above-mentioned secure session.

[0330] 4. If the device needs to access the restricted attributes (distinguishing read, write, add, delete, modify) / methods / events of the peer device, it needs to use the attribute-level token as the verification key to perform a login verification with the peer device.

[0331] 5. The access permissions of multiple different tokens are independent of each other but can be overlaid on the same session. After logging in, the corresponding access permissions are obtained. After logging in, it is possible to log out (the account-level / device-level token used when establishing the session cannot be logged out). After logging out, the corresponding access permissions are cancelled.

[0332] 6. Multiple sessions with the same and / or different permissions are allowed, and the access permissions on multiple sessions are independent of each other.

[0333] Example 3 (Session Token Can Be Logged Out)

[0334] 1. By default, the device uses the account-level token as the PSK to establish a TLS / DTLS / application-layer secure session with the peer device and obtains the account-level access permission without logging in.

[0335] Optionally, the device can establish an anonymous TLS / DTLS / application-layer secure session with the peer device and then use the account-level token to log in to obtain the account-level access permission.

[0336] Optionally, the device can use another key (such as another unified key under the account) as the PSK to establish a TLS / DTLS / application-layer secure session with the peer device and then use the account-level token to log in to obtain the account-level access permission.

[0337] 2. If a device needs to access a peer device in a specific group, it shall use the device-level token as the PSK to establish a TLS / DTLS / application layer security session with the peer device to obtain the device-level access permission.

[0338] 3. If a device needs to access the restricted services of a peer device, it shall use the service-level token as the verification key to perform a login verification with the peer device on the above security session.

[0339] 4. If a device needs to access the restricted attributes (distinguishing read, write, add, delete, modify) / methods / events of a peer device, it shall use the attribute-level token as the verification key to perform a login verification with the peer device.

[0340] 5. The access permissions of multiple tokens are independent of each other but can be superimposed on the same session. The corresponding access permissions are obtained after login. After login, it is possible to log out (for example, the account-level token used when establishing the session can be logged out), and the corresponding access permissions are cancelled after logout.

[0341] 6. Multiple sessions with the same and / or different permissions are allowed, and the access permissions on multiple sessions are independent of each other.

[0342] Example 4 (Establishing a session with any token)

[0343] 1. The device uses any token as the PSK to establish a TLS / DTLS / application layer security session with the peer device, and obtains the access permission corresponding to the token without logging in.

[0344] Optionally, the device can establish an anonymous TLS / DTLS / application layer security session with the peer device, and then use any token to log in to obtain the access permission corresponding to the token.

[0345] Optionally, the device can use other keys (such as another unified key under the account) as the PSK to establish a TLS / DTLS / application layer security session with the peer device, and then use any token to log in to obtain the access permission corresponding to the token.

[0346] 2. The device can use any token as the verification key to perform a login verification with the peer device on the above security session to obtain the access permission corresponding to the token.

[0347] 3. The access permissions of multiple tokens are independent of each other but can be superimposed on the same session. The corresponding access permissions are obtained after login. After login, it is possible to log out (for example, the token used when establishing the session can be logged out), and the corresponding access permissions are cancelled after logout.

[0348] 4. Multiple sessions with the same and / or different permissions are allowed, and the access permissions on multiple sessions are independent of each other.

[0349] Example 5 (Override Permissions)

[0350] 1. By default, the device uses the account-level token as the PSK to establish a TLS / DTLS / application layer secure session with the peer device, and obtains the account-level access permission without logging in.

[0351] Optionally, the device can establish an anonymous TLS / DTLS / application layer secure session with the peer device, and then use the account-level token to log in and obtain the account-level access permission.

[0352] Optionally, the device can use another key (such as another unified key under the account) as the PSK to establish a TLS / DTLS / application layer secure session with the peer device, and then use the account-level token to log in and obtain the account-level access permission.

[0353] 2. If the device needs to access the peer device in a specific group, it needs to use the device-level token as the PSK to establish a TLS / DTLS / application layer secure session with the peer device to obtain the device-level access permission.

[0354] 3. If the device needs to access the restricted services of the peer device, it needs to use the service-level token as the verification key to perform a login verification with the peer device on the above secure session.

[0355] 4. If the device needs to access the restricted attributes (distinguishing read, write, add, delete, modify) / methods / events of the peer device, it needs to use the attribute-level token as the verification key to perform a login verification with the peer device.

[0356] 5. The access permissions of multiple tokens are independent of each other but are overwritten on the same session. After logging in, the corresponding access permission of the token is obtained and the previous permission is automatically cancelled. After logging in, you can log out actively, and the corresponding access permission will be cancelled after logging out.

[0357] 6. It is allowed to have multiple sessions with the same and / or different permissions, and the access permissions on multiple sessions are independent of each other.

[0358] Example 6 (Establish Session with Any Token)

[0359] 1. The device uses any token as the PSK to establish a TLS / DTLS / application layer secure session with the peer device, and obtains the access permission corresponding to the token without logging in.

[0360] Optionally, the device can establish an anonymous TLS / DTLS / application layer secure session with the peer device, and then use any token to log in and obtain the access permission corresponding to the token.

[0361] Optionally, the device may use another key (e.g., another unified key under the account) as the PSK to establish a TLS / DTLS / application layer security session with the peer device, and then use any token to log in to obtain the access rights corresponding to the token.

[0362] 2. The device can use any token as the verification key on the above security session to perform login verification with the peer device to obtain the access rights corresponding to the token.

[0363] 3. The access rights of multiple tokens are independent of each other but are covered on the same session. After logging in, the corresponding access rights of the token are obtained and the previous rights are automatically cancelled. After logging in, one can log out actively, and the corresponding access rights are cancelled after logging out.

[0364] 4. Multiple sessions with the same and / or different permissions are allowed, and the access rights on multiple sessions are independent of each other.

[0365] Example 7 (Using token encryption and decryption)

[0366] 1. The device uses any token as the PSK to establish a TLS / DTLS / application layer security session with the peer device.

[0367] Optionally, the device can establish an anonymous TLS / DTLS / application layer security session with the peer device.

[0368] Optionally, the device may use another key (e.g., another unified key under the account) as the PSK to establish a TLS / DTLS / application layer security session with the peer device.

[0369] 2. The device can use the account-level or device-level or service-level or attribute-level token to encrypt and decrypt communication messages on the above security session. The device can also use the token to generate a communication key using a predefined key generation algorithm such as HMAC / HKDF / PBKDF to encrypt and decrypt communication messages.

[0370] Specifically, the sender can carry the ID of the token in plain text in the message header. The receiver looks up the corresponding token from the token list stored in itself according to the ID, or uses the token to generate a communication key using a predefined key generation algorithm such as HMAC / HKDF / PBKDF, so as to decrypt the message and verify whether the data to be accessed by the message is within the scope of the permissions of the token. If the decryption or verification fails, the controlled device returns a failure to the master device. Optionally, the response message (or called the result message) generated by the receiver can be returned in plain text, or encrypted and returned using the same token and method as the request message (or control message).

[0371] 3. The access permissions of multiple tokens are independent of each other, and the access permission of the current message corresponds to the permission represented by the encryption and decryption key used for this message.

[0372] 4. Multiple sessions are allowed to exist, and the access permissions on multiple sessions are independent of each other.

[0373] Example 8 (Accessing Cloud Relay)

[0374] The device can use account-level or device-level or service-level or attribute-level tokens to encrypt and decrypt communication messages. The device can also use this token to generate a communication key using a predefined key generation algorithm such as HMAC / HKDF / PBKDF to encrypt and decrypt communication messages.

[0375] Specifically, the sender can carry the access token identifier (token ID) in plain text in the message header. The receiver looks up the corresponding token from the token list stored in itself according to the ID, or uses this token to generate a communication key using a predefined key generation algorithm such as HMAC / HKDF / PBKDF, so as to decrypt the message and verify whether the data to be accessed by this message is within the permission range of this token. Optionally, the response message (or called the result message) generated by the receiver can be returned in plain text, or can be encrypted and returned using the same token and method as the request message (or control message).

[0376] The access permissions of multiple tokens are independent of each other, and the access permission of the current message corresponds to the permission represented by the encryption and decryption key used for this message.

[0377] Multiple sessions are allowed to exist between the device and the access cloud, and the access permissions on multiple sessions are independent of each other.

[0378] See Figure 6 , device A is the master device and sends a request message (or control message); device B is the controlled device and receives the request message (or control message). The specific process example is as follows:

[0379] S801 and S802. The device establishes a secure session with the access cloud. For example, device A establishes a secure session with the access cloud, and device B establishes a secure session with the access cloud. S801 and S802 have no timing restrictions, and can occur in sequence or in parallel.

[0380] S803. Device A encrypts the communication message using at least one level of access token (token), and carries the plaintext access token identifier (token ID) and the ID of device B in the message header.

[0381] S804. Device A sends a request message to the access cloud, and the message can carry a message sequence number.

[0382] S805. The access cloud determines to forward the message according to the ID of device B.

[0383] S806. The access cloud forwards the message to device B, and the message may carry a message sequence number.

[0384] S807. Device B obtains the token information from the saved token list according to the token ID, decrypts the request message using the token value and verifies the permission.

[0385] S808. Device B encrypts the result message using the token, and the encrypted message carries the plaintext token ID.

[0386] S809. Device B returns the result message to the access cloud, and the message may carry a message sequence number.

[0387] S810. The access cloud forwards the result message to device A, and the message may carry a message sequence number.

[0388] Optionally, the access cloud caches the source information of the request message, such as the address and port of device A, the ID of device A, and the message sequence number. After receiving the response message, the access cloud finds the source information of the corresponding request message according to the ID of device A and the message sequence number carried in the response message.

[0389] Optionally, the access cloud caches the source information of the request message, such as the address and port of device A, the ID of device A, and the message sequence number. And, the access cloud generates and caches a unique new sequence number to replace the sequence number of the original request message according to the source information. After receiving the response message, the access cloud finds the source information of the corresponding request message according to the message sequence number carried in the response message.

[0390] S811. Device A obtains the token information from the saved token list according to the identifier of the access token (abbreviated as token ID). The token information includes but is not limited to the token ID, the token value, the token permission range, and the token validity period, etc. Device A can decrypt the result message using the token value.

[0391] Example 9 (Access Cloud Proxy Verification)

[0392] The access cloud proxy decrypts the encrypted communication message of the device and verifies whether the data to be accessed is within the permission scope of the token. If the decryption or verification fails, the access cloud directly returns a failure to the master device. Optionally, the receiving party trusts the verification result of the cloud and no longer verifies whether the data to be accessed by the sending party is within the permission scope of the token. Optionally, the decrypted message still carries the token ID, so that the receiving party can also verify again whether the data to be accessed by the sending party is within the permission scope of the token. Optionally, after the cloud verification is successful, the original unencrypted message can be forwarded. Optionally, the response message generated by the receiving party can be returned in plain text or encrypted using the same token and method as the request message and then returned.

[0393] See Figure 7 , Device A is the master device and sends a request message (or control message), and device B is the controlled device and receives the request message (or control message). The specific process example is as follows:

[0394] S901 to S904 can refer to S801 to S804 in Example 8 and will not be elaborated here.

[0395] S905. The access cloud obtains the token information from the saved token list according to the token ID, decrypts the message using the token value, and verifies the message permission using the token permission scope information.

[0396] S906. The access cloud determines to forward the message according to the ID of device B.

[0397] S907. The access cloud forwards the message to device B, and the message can carry a message sequence number.

[0398] S908. Device B obtains the token information from the saved token list according to the token ID and encrypts the result message using the token. The encrypted message carries the plaintext token ID.

[0399] S909 to S911 can refer to S809 to S811 in Example 8 and will not be elaborated here.

[0400] Example 10 (Two access clouds)

[0401] Device A and device B belong to two access clouds, and the access cloud relays the encrypted message. Optionally, the response message generated by the receiving party can be returned in plain text or encrypted using the same token and method as the request message and then returned.

[0402] See Figure 8, Device A is the master device and sends a request message (or control message), while Device B is the controlled device and receives the request message (or control message). The specific process example is as follows:

[0403] S1001 and S1002. The devices establish a secure session with the access cloud. For example, Device A establishes a secure session with access cloud C, and Device B establishes a secure session with access cloud D. S1001 and S1002 have no timing restrictions and can occur in sequence or in parallel.

[0404] S1003. Device A encrypts the communication message using at least one level of token and carries the plaintext token ID and the ID of Device B in the message header.

[0405] S1004. Device A sends a request message to access cloud C, and the message can carry a message sequence number.

[0406] S1005. Access cloud C forwards the message to access cloud D according to the user account association relationship, and the message can carry a message sequence number.

[0407] S1006. Access cloud D forwards the message to Device B according to the device ID.

[0408] S1007. Device B obtains the token information from the saved token list according to the token ID, decrypts the message using the token value, and verifies the message permission using the token permission range information.

[0409] S1008. Device B encrypts the control result message using the token, and the encrypted message carries the plaintext token ID, and the message sequence number is the same as that of the request message.

[0410] S1009. Device B returns the result message to access cloud D.

[0411] S1010. Access cloud D forwards the message to access cloud C according to the message sequence number.

[0412] S1011. Access cloud C forwards the message to Device A according to the message sequence number.

[0413] S1012. Device A obtains the token information from the saved token list according to the token ID. The token information includes, but is not limited to, the token ID, token value, token permission range, and token validity period, etc. Device A can decrypt the result message using the token value.

[0414] Example 11 (Verification of the access cloud proxy at the controlled end)

[0415] Device A and device B belong to two access clouds respectively, and the encrypted message is relayed by the access cloud. It is verified by the access cloud proxy of the controlled device. If the decryption or verification fails, the access cloud returns a failure to the master device. Optionally, the receiving party trusts the verification result of the cloud and does not verify whether the data to be accessed by the sending party is within the permission scope of the token. Optionally, the token ID is still carried in the decrypted message, so that the receiving party can still verify whether the data to be accessed by the sending party is within the permission scope of the token. Optionally, the original unencrypted message can be forwarded after successful cloud verification. Optionally, the response message generated by the receiving party can be returned in plain text or encrypted using the same token and method as the request message.

[0416] See Figure 9 , device A is the master device and sends a request message (or control message), and device B is the controlled device and receives the request message (or control message). The specific process example is as follows:

[0417] S1101 to S1105 can refer to S1001 to S1005 in Example 10 and will not be elaborated here.

[0418] S1106. The access cloud D obtains the token information from the saved token list according to the token ID, decrypts the message using the token value, and verifies the message permission using the token permission scope information.

[0419] S1107. The access cloud D forwards the message to device B according to the device ID. Messages that were not successfully verified in the previous step can be not forwarded.

[0420] S1108. Device B encrypts the control result message using the token. The encrypted message carries the plaintext token ID, and the message sequence number is the same as that of the request message.

[0421] S1109 to S1112 can refer to S1009 to S1012 in Example 10 and will not be elaborated here.

[0422] In the embodiments of the present application, by using multi-level access tokens, IoT devices based on the OLA protocol can control access permissions with finer granularity and improve system security.

[0423] Figure 10 It is a schematic block diagram of a first device 40 according to an embodiment of the present application. The first device 40 may include:

[0424] A control unit 401, configured to perform a first operation using at least one level of access token.

[0425] Optionally, in the embodiments of the present application, the first operation includes at least one of the following:

[0426] Establish a secure session;

[0427] Conduct login verification;

[0428] Encrypt and decrypt communication messages.

[0429] Optionally, in the embodiments of the present application, the ways for the control unit to establish a secure session include at least one of the following:

[0430] Use an account-level access token as a pre-shared key (PSK) to establish a secure session with the second device;

[0431] Use a device-level access token as a PSK to establish a secure session with the second device;

[0432] Use a service-level access token as a PSK to establish a secure session with the second device;

[0433] Use an attribute-level access token as a PSK to establish a secure session with the second device.

[0434] Optionally, in the embodiments of the present application, the secure session includes at least one of the following:

[0435] Transport Layer Security (TLS) session;

[0436] Datagram Transport Layer Security (DTLS) session;

[0437] Application layer secure session.

[0438] Optionally, in the embodiments of the present application, the ways for the control unit to conduct login verification include at least one of the following:

[0439] Use an account-level access token as a verification key to conduct login verification with the second device;

[0440] Use a device-level access token as a verification key to conduct login verification with the second device;

[0441] Use a service-level access token as a verification key to conduct login verification with the second device;

[0442] Use an attribute-level access token as a verification key to conduct login verification with the second device.

[0443] Optionally, in the embodiments of the present application, the algorithm for the login verification is symmetric encryption, and the verification keys used by the first device for login and the second device for verification are the same.

[0444] Optionally, in the embodiments of the present application, the algorithm for login verification is asymmetric encryption. The verification key includes a public key and a private key corresponding to the public key. The first device uses the public key for login, and the second device uses the private key corresponding to the public key for verification.

[0445] Optionally, in the embodiments of the present application, the situations where a device-level access token is used include:

[0446] Needing to access a second device in a specific group.

[0447] Optionally, in the embodiments of the present application, the situations where a service-level access token is used include:

[0448] Needing to access a restricted service of a second device.

[0449] Optionally, in the embodiments of the present application, the situations where an attribute-level access token is used include:

[0450] Needing to access at least one of the restricted attributes, restricted methods, and restricted events of a second device.

[0451] Optionally, in the embodiments of the present application, the restricted attributes of a second device that need to be accessed include at least one of the following operations on the restricted attributes of the second device:

[0452] Read, write, add, delete, and modify.

[0453] Optionally, in the embodiments of the present application, the access permissions of multiple access tokens are stackable in the same session.

[0454] Optionally, in the embodiments of the present application, the access permissions of multiple access tokens are overridable in the same session.

[0455] Optionally, in the embodiments of the present application, the access permissions of multiple access tokens are independent of each other in different sessions.

[0456] Optionally, in the embodiments of the present application, referring to Figure 11 , the ways for the control unit to encrypt and decrypt communication messages include controlling the first sending unit 402 of the first device to perform the following operations:

[0457] Sending a first message, where the first message includes an identifier of a communication key, and the communication key is obtained based on access tokens of at least one level.

[0458] Optionally, in the embodiments of the present application, the communication key is an access token of at least one level; or

[0459] The communication key is a key obtained by encrypting access tokens of at least one level using a first algorithm.

[0460] Optionally, in the embodiments of the present application, the first sending unit is further configured to perform at least one of the following:

[0461] Send the first message to the second device;

[0462] Send the first message to the first cloud, and the first cloud forwards the first message to the second device;

[0463] Send the first message to the second cloud through the first cloud, and the second cloud forwards the first message to the second device;

[0464] Send the first message to the first cloud, and the first cloud decrypts and verifies the first message using the second algorithm and the communication key and then forwards the verified first message to the second device;

[0465] Send the first message to the second cloud through the first cloud, and the second cloud decrypts and verifies the first message using the second algorithm and the communication key and then forwards the verified first message to the second device.

[0466] Optionally, in the embodiments of the present application, the first device further includes:

[0467] A first receiving unit 403, configured to receive a second message, where the second message is a response message to the first message;

[0468] Wherein, the second message is a plaintext message or an encrypted message;

[0469] When the second message is an encrypted message, the second message includes an identifier of the communication key.

[0470] Optionally, in the embodiments of the present application, the first receiving unit is configured to perform at least one of the following:

[0471] Receive the second message from the second device;

[0472] Receive the second message from the first cloud, where the second message is a message received by the first cloud from the second device;

[0473] Receive the second message from the second cloud through the first cloud, where the second message is a message received by the second cloud from the second device;

[0474] Receive the second message from the first cloud, where the second message is a message received by the first cloud from the second device and decrypted and verified through using the second algorithm and the communication key;

[0475] Receive the second message from the second cloud via the first cloud, where the second message is the message received by the second cloud from the second device and decrypted and verified using a second algorithm and a communication key.

[0476] Optionally, in the embodiments of the present application, refer to Figure 12 , the manner in which the control unit encrypts and decrypts communication messages includes controlling the following units of the first device to perform the following operations:

[0477] A second receiving unit 404, configured to receive a first message, where the first message includes an identifier of a communication key, and the communication key is obtained based on at least one level of access token;

[0478] An obtaining unit 405, configured to obtain the at least one level of access token by using the identifier of the communication key;

[0479] A verification unit 406, configured to decrypt and verify the first message by using the obtained at least one level of access token.

[0480] Optionally, in the embodiments of the present application, the communication key is at least one level of access token; or

[0481] The communication key is a key obtained by encrypting at least one level of access token by using a first algorithm.

[0482] Optionally, in the embodiments of the present application, the second receiving unit is configured to perform at least one of the following:

[0483] Receive the first message from the second device;

[0484] Receive the first message from the first cloud, where the first message is the message received by the first cloud from the second device;

[0485] Receive the first message from the second cloud via the first cloud, where the first message is the message received by the second cloud from the second device;

[0486] Receive the first message from the first cloud, where the first message is the message received by the first cloud from the second device and decrypted and verified using a second algorithm and a communication key;

[0487] The first device receives the first message from the second cloud via the first cloud, where the first message is the message received by the second cloud from the second device and decrypted and verified using a second algorithm and a communication key.

[0488] Optionally, in the embodiments of the present application, the first device further includes:

[0489] A second sending unit 407, configured to send a second message, where the second message is a response message to the first message, and the second message includes an identifier of a communication key.

[0490] Optionally, in an embodiment of this application, the second sending unit 407 is configured to perform at least one of the following:

[0491] Send the second message to a second device;

[0492] Send the second message to a first cloud, and the first cloud forwards the second message to the second device;

[0493] Send the second message to a second cloud through a first cloud, and the second cloud forwards the second message to the second device;

[0494] Send the second message to a first cloud, and the first cloud decrypts and verifies the second message using a second algorithm and a communication key, and then forwards the verified second message to the second device;

[0495] Send the second message to a second cloud through a first cloud, and the second cloud decrypts and verifies the second message using a second algorithm and a communication key, and then forwards the verified second message to the second device.

[0496] Optionally, in an embodiment of this application, the algorithm for encrypting and decrypting communication messages is symmetric encryption, and the communication key used for encryption by a sending party and decryption by a receiving party is the same.

[0497] Optionally, in an embodiment of this application, the communication key used for encryption by a sending party and decryption by a receiving party of the second message is the same.

[0498] Optionally, in an embodiment of this application, the algorithm for encrypting and decrypting communication messages is asymmetric encryption, and the communication key includes a public key and a private key corresponding to the public key;

[0499] The first message is encrypted using the public key by a sending party and decrypted using the private key corresponding to the public key by a receiving party.

[0500] Optionally, in an embodiment of this application, the second message is encrypted using the private key by a sending party and decrypted using the public key corresponding to the private key by a receiving party.

[0501] Optionally, in an embodiment of this application, the at least one level of access token includes at least one of the following:

[0502] An access token at the account level;

[0503] An access token at the device level;

[0504] Service-level access token;

[0505] Attribute-level access token.

[0506] Optionally, in the embodiments of the present application, the service-level access token includes:

[0507] Service-level access token of the same device;

[0508] Service-level access token across devices.

[0509] Optionally, in the embodiments of the present application, the attribute-level access token includes:

[0510] Attribute-level access token of the same service;

[0511] Attribute-level access token across services;

[0512] Attribute-level access token across devices.

[0513] Optionally, in the embodiments of the present application, the account-level access token is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of the devices under the same account.

[0514] Optionally, in the embodiments of the present application, the device-level access token is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of the unrestricted services of the same device or multiple devices under the same account.

[0515] Optionally, in the embodiments of the present application, the service-level access token of the same device is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device;

[0516] The service-level access token across devices is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices.

[0517] Optionally, in the embodiments of the present application, the attribute-level access token of the same service is used to access at least one of the restricted attributes, restricted methods, and restricted events of at least one restricted service of the same device of the same service;

[0518] The attribute-level access token across services is used to access at least one of the restricted attributes, restricted methods, and restricted events of at least one restricted service of multiple services of the same device;

[0519] The attribute-level access token across devices is used to access at least one of the restricted attributes, restricted methods, and restricted events of at least one restricted service of multiple services of multiple devices.

[0520] The first device 40 of the embodiment of the present application can implement the corresponding functions of the first device in the foregoing method embodiment. For the corresponding processes, functions, implementation manners, and beneficial effects of each module (sub-module, unit, or component, etc.) in the first device 40, reference may be made to the corresponding descriptions in the foregoing method embodiment, which will not be elaborated herein. It should be noted that the functions described for each module (sub-module, unit, or component, etc.) in the first device 40 of the application embodiment can be implemented by different modules (sub-modules, units, or components, etc.), or by the same module (sub-module, unit, or component, etc.).

[0521] Figure 13 FIG. 4 is a schematic structural diagram of a communication device 600 according to an embodiment of the present application. The communication device 600 includes a processor 610, and the processor 610 can call and run a computer program from a memory, so that the communication device 600 implements the method in the embodiment of the present application.

[0522] Optionally, the communication device 600 may further include a memory 620. Among them, the processor 610 can call and run a computer program from the memory 620, so that the communication device 600 implements the method in the embodiment of the present application.

[0523] Among them, the memory 620 can be a separate device independent of the processor 610, or can be integrated in the processor 610.

[0524] Optionally, the communication device 600 may further include a transceiver 630. The processor 610 can control the transceiver 630 to communicate with other devices. Specifically, it can send information or data to other devices, or receive information or data sent by other devices.

[0525] Among them, the transceiver 630 can include a transmitter and a receiver. The transceiver 630 may further include antennas, and the number of antennas can be one or more.

[0526] Optionally, the communication device 600 can be the second device of the embodiment of the present application, and the communication device 600 can implement the corresponding processes implemented by the second device in each method of the embodiment of the present application. For the sake of brevity, it will not be elaborated herein.

[0527] Optionally, the communication device 600 can be the first device of the embodiment of the present application, and the communication device 600 can implement the corresponding processes implemented by the first device in each method of the embodiment of the present application. For the sake of brevity, it will not be elaborated herein.

[0528] Figure 14It is a schematic structural diagram of a chip 700 according to an embodiment of the present application. The chip 700 includes a processor 710, and the processor 710 can call and run a computer program from a memory to implement the method in the embodiment of the present application.

[0529] Optionally, the chip 700 may further include a memory 720. Among them, the processor 710 can call and run a computer program from the memory 720 to implement the method executed by the first device or the second device in the embodiment of the present application.

[0530] Among them, the memory 720 can be a separate device independent of the processor 710 or integrated in the processor 710.

[0531] Optionally, the chip 700 may further include an input interface 730. Among them, the processor 710 can control the input interface 730 to communicate with other devices or chips. Specifically, it can obtain information or data sent by other devices or chips.

[0532] Optionally, the chip 700 may further include an output interface 740. Among them, the processor 710 can control the output interface 740 to communicate with other devices or chips. Specifically, it can output information or data to other devices or chips.

[0533] Optionally, the chip can be applied to the second device in the embodiment of the present application, and the chip can implement the corresponding processes implemented by the second device in each method of the embodiment of the present application. For the sake of brevity, it will not be elaborated here.

[0534] Optionally, the chip can be applied to the first device in the embodiment of the present application, and the chip can implement the corresponding processes implemented by the first device in each method of the embodiment of the present application. For the sake of brevity, it will not be elaborated here.

[0535] The chips applied to the second device and the first device can be the same chip or different chips.

[0536] It should be understood that the chip mentioned in the embodiment of the present application can also be called a system-on-chip, system chip, chip system, or system-on-chip, etc.

[0537] The above-mentioned processor may be a general-purpose processor, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other programmable logic devices, transistor logic devices, discrete hardware components, etc. Among them, the above-mentioned general-purpose processor may be a microprocessor or any conventional processor, etc.

[0538] The above-mentioned memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM).

[0539] It should be understood that the above memory is an exemplary but not restrictive description. For example, the memory in the embodiments of the present application may also be a static random access memory (SRAM), a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), a double data rate synchronous dynamic random access memory (DDR SDRAM), an enhanced synchronous dynamic random access memory (ESDRAM), a synch link DRAM (SLDRAM), and a direct rambus random access memory (DR RAM), etc. That is to say, the memory in the embodiments of the present application is intended to include but not limited to these and any other suitable types of memory.

[0540] Figure 15 It is a schematic block diagram of a communication system 800 according to an embodiment of the present application. The communication system 800 includes a first device 810 and a second device 820.

[0541] The first device 810 is configured to perform a first operation using at least one level of access token.

[0542] Optionally, the first operation includes at least one of the following:

[0543] Establish a secure session;

[0544] Perform a login verification;

[0545] Encrypt and decrypt communication messages.

[0546] Optionally, the first device 810 establishes a secure session with the second device 820 using at least one level of access token.

[0547] Optionally, the first device 810 performs a login verification with the second device 820 using at least one level of access token.

[0548] Optionally, the first device 810 and the second device 820 encrypt and decrypt communication messages using at least one level of access token.

[0549] Wherein, the first device 810 can be used to implement the corresponding functions implemented by the first device in the above method, and the second device 820 can be used to implement the corresponding functions implemented by the second device in the above method. For the sake of brevity, details are not described herein again.

[0550] 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, all or part of the processes or functions in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. 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 in a wired manner (such as coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a Solid State Disk (SSD)), etc.

[0551] It should be understood that in various embodiments of the present application, the magnitudes of the serial numbers of the above processes do not mean the sequence of execution, and the execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0552] Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments, and will not be described herein again.

[0553] The above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application, and all should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for using an access token, comprising: The first device performs a first operation using at least one level of access token, and the first operation includes at least one of the following: Establishing a secure session, and the way of establishing the secure session includes at least one of the following: when accessing a certain account or by default, establishing a secure session with the second device using the account-level access token; when accessing a second device in a specific group, establishing a secure session with the second device using the device-level access token; When accessing a restricted service of the second device, establishing a secure session with the second device using the service-level access token; When accessing at least one of the restricted attributes, restricted methods, and restricted events of the second device, establishing a secure session with the second device using the attribute-level access token, wherein the first device establishes multiple secure sessions with the second device using multiple levels of access tokens, and on different secure sessions, the permission scopes of multiple levels of access tokens are independent of each other, and on the same session, the permission scopes of multiple levels of access tokens are superimposed or overlaid; Performing login verification, wherein when accessing a certain account or by default, using the account-level access token as the verification key to perform login verification with the second device; when accessing a second device in a specific group, using the device-level access token as the verification key to perform login verification with the second device; when accessing a restricted service of the second device, using the service-level access token as the verification key to perform login verification with the second device; when accessing at least one of the restricted attributes, restricted methods, and restricted events of the second device, using the attribute-level access token as the verification key to perform login verification with the second device.

2. The method according to claim 1, wherein, The secure session includes at least one of the following: Transport Layer Security (TLS) session; Datagram Transport Layer Security (DTLS) session; Application layer secure session.

3. The method according to claim 1, wherein The algorithm for the login verification is symmetric encryption, and the verification key used by the first device for login and the second device for verification is the same.

4. The method according to claim 1, wherein The algorithm for the login verification is asymmetric encryption, the verification key includes a public key and a private key corresponding to the public key, the first device uses the public key for login, and the second device uses the private key corresponding to the public key for verification.

5. The method according to claim 1, wherein The situations where the device-level access token is used include: Needing to access a second device in a specific group.

6. The method according to claim 1, wherein The situations where the service-level access token is used include: Needing to access a restricted service of the second device.

7. The method according to claim 1, wherein The situations where the attribute-level access token is used include: Needing to access at least one of the restricted attributes, restricted methods, and restricted events of the second device.

8. The method according to claim 7, wherein Needing to access the restricted attributes of the second device includes needing to perform at least one of the following operations on the restricted attributes of the second device: Read, write, add, delete, and modify.

9. The method according to claim 1, wherein The first operation further includes encrypting and decrypting communication messages, and the way of encrypting and decrypting communication messages includes: The first device sends a first message, and the first message includes an identifier of a communication key, and the communication key is obtained based on at least one level of access token.

10. The method according to claim 9, wherein, the communication key is an access token of at least one level; or the communication key is a key obtained by encrypting an access token of at least one level using a first algorithm.

11. The method according to claim 9 or 10, wherein The first device sending the first message includes at least one of the following: the first device sending the first message to the second device; the first device sending the first message to the first cloud, and the first cloud forwarding the first message to the second device; the first device sending the first message to the second cloud through the first cloud, and the second cloud forwarding the first message to the second device; the first device sending the first message to the first cloud, and the first cloud decrypting and verifying the first message using a second algorithm and the communication key and then forwarding the verified first message to the second device; the first device sending the first message to the second cloud through the first cloud, and the second cloud decrypting and verifying the first message using a second algorithm and the communication key and then forwarding the verified first message to the second device.

12. The method according to claim 11, wherein, The method further includes: the first device receiving a second message, where the second message is a response message to the first message; wherein, the second message is a plaintext message or an encrypted message; in the case where the second message is an encrypted message, the second message includes an identifier of the communication key.

13. The method according to claim 12, wherein, The first device receiving the second message includes at least one of the following: the first device receiving the second message from the second device; the first device receiving the second message from the first cloud, where the second message is a message received by the first cloud from the second device; the first device receiving the second message from the second cloud through the first cloud, where the second message is a message received by the second cloud from the second device; the first device receiving the second message from the first cloud, where the second message is a message received by the first cloud from the second device and decrypted and verified using a second algorithm and the communication key; the first device receiving the second message from the second cloud through the first cloud, where the second message is a message received by the second cloud from the second device and decrypted and verified using a second algorithm and the communication key.

14. The method according to claim 9, wherein, The method for encrypting and decrypting communication messages includes: the first device receiving a first message, where the first message includes an identifier of a communication key, and the communication key is obtained based on an access token of at least one level; the first device obtaining the access token of at least one level using the identifier of the communication key; the first device decrypting and verifying the first message using the obtained access token of at least one level.

15. The method according to claim 14, wherein, the communication key is an access token of at least one level; or the communication key is a key obtained by encrypting an access token of at least one level using a first algorithm.

16. The method according to claim 14 or 15, wherein The first device receiving the first message includes at least one of the following: the first device receiving the first message from the second device; The first device receives the first message from the first cloud, and the first message is the message received by the first cloud from the second device; The first device receives the first message from the second cloud through the first cloud, and the first message is the message received by the second cloud from the second device; The first device receives the first message from the first cloud, and the first message is the message received by the first cloud from the second device and decrypted and verified through the second algorithm and the communication key; The first device receives the first message from the second cloud through the first cloud, and the first message is the message received by the second cloud from the second device and decrypted and verified through the second algorithm and the communication key.

17. The method according to claim 16, wherein The method further includes: The first device sends a second message, and the second message is a response message to the first message, and the second message includes an identifier of the communication key.

18. The method according to claim 17, wherein, The first device sending the second message includes at least one of the following: The first device sends the second message to the second device; The first device sends the second message to the first cloud, and the first cloud forwards the second message to the second device; The first device sends the second message to the second cloud through the first cloud, and the second cloud forwards the second message to the second device; The first device sends the second message to the first cloud, and the first cloud decrypts and verifies the second message using the second algorithm and the communication key and then forwards the verified second message to the second device; The first device sends the second message to the second cloud through the first cloud, and the second cloud decrypts and verifies the second message using the second algorithm and the communication key and then forwards the verified second message to the second device.

19. The method according to claim 18, wherein, The algorithm for encrypting and decrypting communication messages is symmetric encryption, and the communication key used for encryption by the sender and decryption by the receiver of the first message is the same.

20. The method according to claim 19, wherein The communication key used for encryption by the sender and decryption by the receiver of the second message is the same.

21. The method according to claim 12, wherein, The algorithm for encrypting and decrypting communication messages is asymmetric encryption, and the communication key includes a public key and a private key corresponding to the public key; The first message is encrypted by the sender using the public key and decrypted by the receiver using the private key corresponding to the public key.

22. The method according to claim 21, wherein, The second message is encrypted by the sender using the private key and decrypted by the receiver using the public key corresponding to the private key.

23. The method according to claim 1, wherein The at least one level of access token includes at least one of the following: The access token at the account level; The access token at the device level; The access token at the service level; The access token at the attribute level.

24. The method according to claim 23, wherein, The access token at the service level includes: The access token at the service level of the same device; The access token at the service level across devices.

25. The method according to claim 23, wherein The access token at the attribute level includes: The access token at the attribute level of the same service; The access token at the attribute level across services; The access token at the attribute level across devices.

26. The method according to claim 23, wherein The access token at the account level is used to access at least one of the unrestricted services, unrestricted attributes, unrestricted methods, and unrestricted events of the devices under the same account.

27. The method according to claim 23, wherein Device-level access tokens are used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services of the same device or multiple devices under the same account.

28. The method according to claim 24, wherein Service-level access tokens for the same device are used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device; Service-level access tokens across devices are used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices.

29. The method according to claim 25, wherein Attribute-level access tokens for the same service are used to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device; Attribute-level access tokens across services are used to access at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device; Attribute-level access tokens across devices are used to access at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices.

30. A first device applying an access token usage method, comprising: A control unit configured to perform a first operation using at least one level of access token, the first operation including at least one of the following: Establishing a secure session, and the way of establishing the secure session includes at least one of the following: using an account-level access token to establish a secure session with a second device when accessing a certain account or by default; using a device-level access token to establish a secure session with a second device when accessing a second device in a specific group; Using a service-level access token to establish a secure session with a second device when accessing a restricted service of the second device; Using an attribute-level access token to establish a secure session with a second device when accessing at least one of the restricted attributes, restricted methods, and restricted events of the second device, wherein the first device uses multiple levels of access tokens to establish multiple secure sessions with the second device, and on different secure sessions, the permission scopes of the multiple levels of access tokens are independent of each other, and on the same session, the permission scopes of the multiple levels of access tokens are superimposed or overlaid; Performing login verification, wherein when accessing a certain account or by default, using an account-level access token as a verification key to perform login verification with a second device; when accessing a second device in a specific group, using a device-level access token as a verification key to perform login verification with a second device; when accessing a restricted service of the second device, using a service-level access token as a verification key to perform login verification with a second device; when accessing at least one of the restricted attributes, restricted methods, and restricted events of the second device, using an attribute-level access token as a verification key to perform login verification with a second device.

31. The first device according to claim 30, wherein, The secure session includes at least one of the following: Transport Layer Security (TLS) session; Datagram Transport Layer Security (DTLS) session; Application layer secure session.

32. The first device according to claim 30, wherein, The algorithm for the login verification is symmetric encryption, and the verification key used by the first device for login and the second device for verification is the same.

33. The first device according to claim 30, wherein, The algorithm for the login verification is asymmetric encryption. The verification key includes a public key and a private key corresponding to the public key. The first device uses the public key for login, and the second device uses the private key corresponding to the public key for verification.

34. The first device according to claim 30, wherein, Situations where a device-level access token is used include: Needing to access a second device in a specific group.

35. The first device according to claim 30, wherein, Situations where a service-level access token is used include: Needing to access restricted services of a second device.

36. The first device according to claim 30, wherein, Situations where an attribute-level access token is used include: Needing to access at least one of the restricted attributes, restricted methods, and restricted events of a second device.

37. The first device according to claim 36, wherein, Needing to access the restricted attributes of a second device includes needing to perform at least one of the following operations on the restricted attributes of the second device: Read, write, add, delete, and modify.

38. The first device according to claim 30, wherein, The control unit encrypts and decrypts communication messages by controlling the first sending unit of the first device to perform the following operations: Send a first message, where the first message includes an identifier of a communication key, and the communication key is obtained based on access tokens of at least one level.

39. The first device according to claim 38, wherein The communication key is an access token of at least one level; or The communication key is a key obtained by encrypting an access token of at least one level using a first algorithm.

40. The first device according to claim 38 or 39, wherein, The first sending unit is further configured to perform at least one of the following: Send the first message to the second device; Send the first message to the first cloud, and the first cloud forwards the first message to the second device; Send the first message to the second cloud through the first cloud, and the second cloud forwards the first message to the second device; Send the first message to the first cloud, and the first cloud decrypts and verifies the first message using a second algorithm and the communication key and then forwards the verified first message to the second device; Send the first message to the second cloud through the first cloud, and the second cloud decrypts and verifies the first message using a second algorithm and the communication key and then forwards the verified first message to the second device.

41. The first device according to claim 40, wherein, The first device further includes: A first receiving unit, configured to receive a second message, where the second message is a response message to the first message; Wherein, the second message is a plaintext message or an encrypted message; In the case where the second message is an encrypted message, the second message includes an identifier of the communication key.

42. The first device according to claim 41, wherein, The first receiving unit is configured to perform at least one of the following: Receive the second message from the second device; Receive the second message from the first cloud, where the second message is a message received by the first cloud from the second device; Receive the second message from the second cloud through the first cloud, where the second message is a message received by the second cloud from the second device; Receive the second message from the first cloud, where the second message is a message received by the first cloud from the second device and decrypted and verified through using a second algorithm and the communication key; Receive the second message from the second cloud by the first cloud, where the second message is the message received by the second cloud from the second device and decrypted and verified through a second algorithm and a communication key.

43. The first device according to claim 30, wherein, The control unit's way of encrypting and decrypting communication messages includes controlling the second receiving unit of the first device to perform the following operations: Receive a first message, where the first message includes an identifier of a communication key, and the communication key is obtained based on at least one level of access token; Obtain the at least one level of access token using the identifier of the communication key; Use the obtained at least one level of access token to decrypt and verify the first message.

44. The first device according to claim 43, wherein The communication key is at least one level of access token; or The communication key is a key obtained by encrypting at least one level of access token using a first algorithm.

45. The first device according to claim 43 or 44, wherein The second receiving unit is used to perform at least one of the following: Receive the first message from the second device; Receive the first message from the first cloud, where the first message is the message received by the first cloud from the second device; Receive the first message from the second cloud by the first cloud, where the first message is the message received by the second cloud from the second device; Receive the first message from the first cloud, where the first message is the message received by the first cloud from the second device and decrypted and verified through a second algorithm and a communication key; The first device receives the first message from the second cloud by the first cloud, where the first message is the message received by the second cloud from the second device and decrypted and verified through a second algorithm and a communication key.

46. The first device according to claim 45, wherein, The first device further includes: A second sending unit for sending a second message, where the second message is a response message to the first message, and the second message includes an identifier of a communication key.

47. The first device according to claim 46, wherein, The second sending unit is used to perform at least one of the following: Send the second message to the second device; Send the second message to the first cloud, and the first cloud forwards the second message to the second device; Send the second message to the second cloud through the first cloud, and the second cloud forwards the second message to the second device; Send the second message to the first cloud, and the first cloud decrypts and verifies the second message using a second algorithm and a communication key and then forwards the verified second message to the second device; Send the second message to the second cloud through the first cloud, and the second cloud decrypts and verifies the second message using a second algorithm and a communication key and then forwards the verified second message to the second device.

48. The first device according to claim 47, wherein, The algorithm for encrypting and decrypting communication messages is symmetric encryption, and the communication key used for encrypting the first message by the sender is the same as the communication key used for decrypting it by the receiver.

49. The first device according to claim 48, wherein, The communication key used for encrypting the second message by the sender is the same as the communication key used for decrypting it by the receiver.

50. The first device according to claim 49, wherein, The algorithm for encrypting and decrypting communication messages is asymmetric encryption, and the communication key includes a public key and a private key corresponding to the public key; The first message is encrypted using the public key at the sender side and decrypted using the private key corresponding to the public key at the receiver side.

51. The first device according to claim 50, wherein, The second message is encrypted using the private key at the sender side and decrypted using the public key corresponding to the private key at the receiver side.

52. The first device according to claim 30, wherein, The at least one level of access token includes at least one of the following: The access token at the account level; The access token at the device level; The access token at the service level; The access token at the attribute level.

53. The first device according to claim 52, wherein, The access token at the service level includes: The access token at the service level for the same device; The access token at the service level across devices.

54. The first device according to claim 52, wherein, The access token at the attribute level includes: The access token at the attribute level for the same service; The access token at the attribute level across services; The access token at the attribute level across devices.

55. The first device according to claim 52, wherein, The access token at the account level is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of the services of the devices under the same account.

56. The first device according to claim 52, wherein, The access token at the device level is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of the services of the same device or multiple devices under the same account.

57. The first device according to claim 53, wherein, The access token at the service level for the same device is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device; The access token at the service level across devices is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices.

58. The first device according to claim 52, wherein, The access token at the attribute level for the same service is used to access at least one of the restricted attributes, restricted methods, and restricted events of at least one service of the same device; The access token at the attribute level across services is used to access at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device; The access token at the attribute level across devices is used to access at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices.

59. A first device using a method for an application access token, comprising: A processor and a memory, the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory, so that the first device executes the method according to any one of claims 1 to 29.

60. A chip, comprising: A processor, used to call and run a computer program from a memory, so that the device installed with the chip executes the method according to any one of claims 1 to 29.

61. A computer-readable storage medium, used to store a computer program, when the computer program is run by a device, the device executes the method according to any one of claims 1 to 29.

62. A computer program product, including computer program instructions, the computer program instructions enable a computer to execute the method according to any one of claims 1 to 29.

Images