Method and apparatus for wireless communication
By transmitting only role information in cross-Fabric interconnection scenarios, the problem of information leakage caused by sharing configuration device permissions is solved, ensuring the security and integrity of permissions.
Patent Information
- Application Number
- CN202180093432.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-04-15
- Publication Date
- 2026-08-25
- Estimated Expiration
- 2041-04-15
AI Technical Summary
In cross-Fabric interconnection scenarios, when a configuration device with administrator privileges in Fabric A shares its administrator privileges with Fabric B, the privileges of the configuration device in Fabric B are expanded, which may lead to the leakage of information in Fabric A.
By transmitting only the role information of the second configuration device during the permission sharing process, the first configuration device can obtain access to the smart terminal, thus avoiding the transmission of sensitive information.
This achieves the prevention of A Fabric information leakage during the permission sharing process, and the first configured device only obtains the access permissions represented by the role information, thus avoiding the expansion of its permissions.
Smart Images

Figure CN116868188B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of the Internet of Things, and more specifically, to a method and apparatus for wireless communication. Background Technology
[0002] In cross-fabric interconnection scenarios, a configuration device with administrator privileges in Fabric A might share its administrator privileges with a configuration device in Fabric B. However, during this sharing process, the configuration device with administrator privileges in Fabric A needs to send Fabric A's certificate and Fabric A information to the configuration device in Fabric B, allowing the configuration device in Fabric B to join Fabric A and gain Fabric A's administrator privileges. However, this expands the permissions of the configuration device in Fabric B and could also lead to the leakage of Fabric A information. Summary of the Invention
[0003] This application provides a wireless communication method and device that can prevent the leakage of Fabric information of the permission sharing party.
[0004] In a first aspect, a wireless communication method is provided, the method comprising:
[0005] The first configuration device receives role information, which is used to indicate the role of the device represented by the certificate;
[0006] The first configuration device sends first information to the smart terminal, the first information including a target application certificate, and the target application certificate includes at least the role information.
[0007] Secondly, a wireless communication method is provided, the method comprising:
[0008] The smart terminal receives first information sent by the first configuration device. The first information includes a target application certificate, and the target application certificate includes role information, which is used to indicate the role of the device represented by the certificate.
[0009] The smart terminal determines the access permissions of the first configured device based on the role information.
[0010] Thirdly, a wireless communication method is provided, the method comprising:
[0011] The second configuration device sends role information to the first configuration device, which is used to indicate the role of the device represented by the certificate.
[0012] Fourthly, a configuration device is provided for performing the method described in the first aspect above.
[0013] Specifically, the configuration device includes a functional module for performing the method in the first aspect described above.
[0014] Fifthly, a smart terminal is provided for performing the method described in the second aspect above.
[0015] Specifically, the smart terminal includes a functional module for performing the method described in the second aspect above.
[0016] Sixthly, a configuration device is provided for performing the method described in the third aspect above.
[0017] Specifically, the configuration device includes a functional module for performing the method described in the third aspect above.
[0018] In a seventh aspect, a configuration device is provided, including a processor and a memory. The memory is used to store a computer program, and the processor is used to invoke and run the computer program stored in the memory to perform the method described in the first aspect.
[0019] Eighthly, a smart terminal is provided, including a processor and a memory. The memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to perform the methods described in the second aspect above.
[0020] A ninth aspect provides a configuration device including a processor and a memory. The memory is used to store a computer program, and the processor is used to invoke and run the computer program stored in the memory to perform the method described in the third aspect above.
[0021] In a tenth aspect, an apparatus is provided for implementing the method in any one of the first to third aspects described above.
[0022] Specifically, the device includes a processor for retrieving and running a computer program from a memory, causing a device equipped with the device to perform the method described in any of the first to third aspects above.
[0023] Eleventhly, a computer-readable storage medium is provided for storing a computer program that causes a computer to perform the methods of any one of the first to third aspects described above.
[0024] In a twelfth aspect, a computer program product is provided, comprising computer program instructions that cause a computer to perform the methods of any one of the first to third aspects described above.
[0025] In a thirteenth aspect, a computer program is provided that, when run on a computer, causes the computer to perform the methods of any one of the first to third aspects described above.
[0026] Through the above technical solution, the second configuration device can share role information with the first configuration device, thereby enabling the first configuration device to obtain access permissions to the smart terminal through the role information. In the permission sharing process, only the role information of the second configuration device is transmitted, avoiding the information leakage problem in the Fabric where the first configuration device is located. Moreover, the first configuration device only obtains the access permissions represented by the role information, avoiding the expansion of the permissions of the first configuration device. Attached Figure Description
[0027] Figure 1 This is a flowchart of a permission sharing method provided in this application.
[0028] Figure 2 This is a schematic diagram of a wireless communication system used in an embodiment of this application.
[0029] Figure 3 This is a schematic interactive flowchart of a wireless communication method provided in an embodiment of this application.
[0030] Figure 4 This is a schematic interactive flowchart of another wireless communication method provided in the embodiments of this application.
[0031] Figure 5 This is a schematic interactive flowchart of another wireless communication method provided in the embodiments of this application.
[0032] Figure 6 A schematic block diagram of a configuration device according to an embodiment of this application is shown.
[0033] Figure 7 A schematic block diagram of a smart terminal according to an embodiment of this application is shown.
[0034] Figure 8 A schematic block diagram of another configured device according to an embodiment of this application is shown.
[0035] Figure 9 This is a schematic structural diagram of a communication device provided in an embodiment of this application.
[0036] Figure 10 This is a schematic structural diagram of the device according to an embodiment of this application. Detailed Implementation
[0037] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art without creative effort regarding the embodiments of this application are within the scope of protection of this application.
[0038] In the Internet of Things (IoT) field, different manufacturers can establish different Fabrics. Devices can be configured to access and control one or more smart terminals within the same Fabric, such as controlling a smart light bulb via a mobile phone to turn it on or off. Within the same Fabric, devices can obtain the Fabric's root certificate and information. A configuration device with administrator privileges within the same Fabric can share its administrator privileges with other configuration devices, granting those devices administrator privileges for one or more smart terminals within that Fabric. However, in cross-Fabric interoperability scenarios, a configuration device with administrator privileges in Fabric A might share its administrator privileges with a configuration device in Fabric B. During this sharing process, the configuration device with administrator privileges in Fabric A needs to send Fabric A's certificate and information to the configuration device in Fabric B, allowing the device in Fabric B to join Fabric A and gain administrator privileges. This expands the permissions of the configuration device in Fabric B and can also lead to the leakage of Fabric A's information.
[0039] For example, such as Figure 1 As shown, User A purchased a smart light bulb, a product certified by the Connected Home over IP Working Group (CHIP) under the Alliance, and supporting Bluetooth Low Energy (BLE) and / or Wireless Fidelity (WiFi). User A configures the smart light bulb in the living room using an A-APP on their phone, and can later control the smart light bulb using the A-APP. In this case, the A-APP acts as an Admin, Commissioner, and Controller. User A adds the B-APP to User B's phone, acting as a second Admin and Controller for the smart light bulb. User A can specifically share their administrator privileges with User B through S01-S027.
[0040] S01. User B triggers the B-APP on their phone to join User A's family (i.e., User A's Fabric);
[0041] S02. User B's B-APP generates a QR code;
[0042] S03. User B's B-APP starts pairing broadcast;
[0043] S04. User B's B-APP obtains the certificate chain from the certificate authority (CA) device corresponding to User B;
[0044] S05. User B shares a QR code with User A;
[0045] S06. User A triggers A-APP to add User B to User A's family (i.e. User A's Fabric);
[0046] S07. A-APP obtains the QR code information of B-APP;
[0047] S08.A - APP starts pairing scan;
[0048] S09. A-APP establishes a connection with B-APP;
[0049] S010. A-APP and B-APP establish a secure channel by negotiating the information in the QR code;
[0050] S011. A-APP obtains an authentication request from B-APP, which includes B-APP's signature and certificate chain;
[0051] S012.A-APP Authentication B-APP;
[0052] S013. A-APP applies for a certificate from B-APP to the CA device corresponding to user A;
[0053] S014.A - The APP sends a confirmation request to user A;
[0054] S015. User A confirms granting permissions to User B;
[0055] S016.A-APP generates the corresponding Access Control List Entry (ACLE);
[0056] S017.A-APP configures ACLE for smart bulbs;
[0057] S018.A-APP sends the root certificate corresponding to user A, the certificate generated by the CA device corresponding to user A for B-APP, and Fabric information to B-APP;
[0058] S019.B-APP establishes a secure channel between the certificate it generates for itself and the smart bulb through the CA device corresponding to user A;
[0059] S020.B - APP obtains authentication request for smart bulb;
[0060] S021.B-APP certified smart bulb;
[0061] S022.B-APP applies for a certificate for the smart bulb using the corresponding CA device for user B;
[0062] S023.B-APP configures the applied certificate chain to the smart bulb;
[0063] S024.B - The APP closes the security channel established with the smart bulb;
[0064] S025.B-APP establishes a secure channel between the certificate it generates for itself and the smart bulb through the CA device corresponding to User A;
[0065] S026.B-APP generates ACLE;
[0066] S027.B-APP configures ACLE for smart bulbs.
[0067] In this scenario, User B can use the B-APP to control the smart light bulb and view its status. User B's B-APP can also configure other smart devices in User A's home (i.e., User A's Fabric).
[0068] In the above Figure 1 In S018, user A configures B-APP into A Fabric. B-APP obtains A Fabric's Fabric information and A Fabric certificate, expanding B-APP's permissions and potentially causing leakage of sensitive information in A Fabric.
[0069] It should be noted that Fabric can also be understood as a platform, ecosystem, or similar descriptions, and this application does not limit it in this way.
[0070] To address the aforementioned issues, this application proposes an access permission sharing scheme. A configuration device with administrator privileges in Fabric A can share its role information with a configuration device in Fabric B, thereby enabling the configuration device in Fabric B to obtain access permissions to smart terminals in Fabric A based on the role information. This avoids expanding the permissions of the configuration device in Fabric B and also prevents information leakage in Fabric A.
[0071] To facilitate a better understanding of the embodiments of this application, the access control lists (ACLs) related to this application are explained.
[0072] ACL is a packet filtering-based access control technology that can filter data packets on an interface based on set conditions, allowing them to pass or dropping them.
[0073] An ACL consists of several Access Control List Entry (ACLE) entries. The structure of each ACLE is shown in Table 1 below.
[0074] Table 1
[0075]
[0076]
[0077] In Table 1 above, the term "subject" primarily refers to the use of a given authentication method provided by the secure channel architecture to describe the origin of an operation. The subject should be:
[0078] 1. An initiating node that interacts during the debugging phase through a Password Authenticated Session Establishment (PASE) session, implicitly identified by the fact that the two peers in the PASE session authenticate each other locally.
[0079] 2. The initiating node that interacts through a CASE session during the operation phase is identified using a distinguishable name (e.g., node ID) from the operation certificate (OpCert) shared during session establishment;
[0080] 3. A group is an initiating program node that interacts through message groups. It is identified by a group ID and verified by an operation group key.
[0081] The technical solutions of this application can be applied to various communication systems, such as WiFi, BLE, Wireless Local Area Networks (WLAN), mobile communication networks, Near Field Communication (NFC), Ultra Broadband (UWB) networks, infrared networks, microwave communication networks, millimeter-wave communication networks, and free-space optical communication networks. This application can also be applied to device-to-device (D2D) communication, machine-to-machine (M2M) communication, machine-type communication (MTC), vehicle-to-vehicle (V2V) communication, or vehicle-to-everything (V2X) communication, etc.
[0082] Figure 2 This is a schematic diagram of a wireless communication system provided in an embodiment of this application. Figure 2 As shown, the wireless communication system 100 may include: a first configuration device 110, a second configuration device 120, a CA device 130, and a smart terminal 140.
[0083] In some embodiments, the first configuration device 110 and / or the second configuration device 120 may be a terminal device, such as a mobile phone, tablet computer, computer, wireless local loop (WLL) station, personal digital assistant (PDA) device, handheld device with wireless communication capabilities, computing device or other processing device connected to a wireless modem, in-vehicle device, smart wearable device, etc.
[0084] In some embodiments, the first configuration device 110 and / or the second configuration device 120 may also be a server.
[0085] In some embodiments, the first configuration device 110 and the second configuration device 120 may belong to different fabrics.
[0086] In some embodiments, the second configuration device 120 and the smart terminal 140 belong to the same Fabric, and the second configuration device 120 has access permissions (such as administrator permissions) to the smart terminal 140. The second configuration device 120 can access and control the smart terminal 140 through these access permissions.
[0087] In some embodiments, the first configuration device 110 and the second configuration device 120 can be connected via wired or wireless means, and the second configuration device 120 can share access permissions to the smart terminal 140 with the first configuration device 110.
[0088] In some embodiments, the smart terminal 140 is connected to the second configuration device 120 via a wired or wireless means. The smart terminal 140 can be any of the aforementioned terminal devices. More often, the smart terminal 140 can be a smart home product, such as a smart refrigerator, smart light bulb, smart washing machine, smart TV, smart wearable device, etc.
[0089] In some embodiments, wearable devices can also be called wearable smart terminals. This refers to a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices worn directly on the body or integrated into a user's clothing or accessories. Wearable devices are not merely hardware devices; they achieve powerful functions through software support, data interaction, and cloud interaction. Broadly defined, wearable smart terminals include those with comprehensive functions, large sizes, and the ability to perform complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses. They also include devices focused on a specific application function that require interaction with other devices like smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.
[0090] In some embodiments, the smart terminal 140 may also be connected to a first configuration device 110 that has access to the smart terminal 140 via a wired or wireless means, and the first configuration device 110 may access and control the smart terminal 140 through the access permissions.
[0091] In some embodiments, the CA device 130 may be a device with certificate authorization authority. The CA device 130 is connected to the first configuration device 110 via wired or wireless means, and the CA device 130 can generate corresponding application certificates for the first configuration device 110 or update application certificates through interaction.
[0092] In some embodiments, the number of smart terminals 140 can be one or more, and this application does not limit this.
[0093] The technical solution of this application is described in detail below through specific embodiments.
[0094] Figure 3 This is a schematic interactive flowchart of a wireless communication method 200 provided in an embodiment of this application, such as... Figure 3 As shown, the wireless communication method 200 may include at least the following:
[0095] S201. The second configuration device sends role information to the first configuration device, the role information being used to indicate the role of the device represented by the certificate;
[0096] Correspondingly, the first configuration device receives the role information sent by the second configuration device;
[0097] S205. The first configuration device sends first information to the smart terminal, the first information including the target application certificate, and the target application certificate includes at least the role information.
[0098] It should be noted that the role of each configuration device relative to the smart terminal can be reflected in the certificate corresponding to the configuration device. For example, it could be an administrator role with administrator privileges, and the role information can be used to indicate the role of the configuration device represented by the certificate to the smart terminal. Optionally, each configuration device can have the same permissions for multiple smart terminals, or it can have different permissions for multiple smart terminals.
[0099] For example, the second configuration device can directly send role information to the first configuration device, or it can send a Node Operational Certificate (NOC) containing role information to the first configuration device, so that the first configuration device can read the role information from the NOC certificate.
[0100] For example, the first configuration device may initiate a connection establishment request to the smart terminal, and after the connection is established, send first information carrying the target application certificate to the smart terminal.
[0101] The target application certificate is the certificate corresponding to the first configuration device, and the role information in the target application certificate is used to represent the role of the first configuration device.
[0102] In some embodiments, the target application certificate is used by the smart terminal to determine the access permissions of the first configured device.
[0103] Combination Figure 3 As shown, before the first configuration device sends the first information to the smart terminal, or in other words, before the first configuration device establishes a connection with the smart terminal, the wireless communication method 200 may further include at least some of the following:
[0104] S202. The first configuration device sends second information to the CA device, the second information being used to request an update of the application certificate, and the second information including at least role information;
[0105] The S203.CA device sends third information to the first configuration device, which includes the target application certificate;
[0106] S204. The second configuration device sends the root certificate of the first configuration device to the smart terminal;
[0107] This embodiment does not require the execution order of S204 and S202 or S203.
[0108] The following explanation is provided for S202 and S203:
[0109] In order for the application certificate of the second configuration device to contain role information, the second configuration device needs to request the CA device to update the first application certificate to the target application certificate with role information. For example, the CA device can add the role information to the first application certificate according to the second information, and sign the first application certificate with added role information to obtain the target application certificate.
[0110] Optionally, the second information may also include the first application certificate.
[0111] For example, the second configuration device configures the root certificate of the first configuration device on the smart terminal, so that the smart terminal regards the root certificate of the first configuration device as a trusted root certificate.
[0112] Combination Figure 3 As shown, after the first configuration device sends the first information to the smart terminal, the wireless communication method 200 may further include at least some of the following:
[0113] S206. The smart terminal verifies the target application certificate using the root certificate of the first configuration device;
[0114] S207. The smart terminal determines the access permissions of the first configured device based on the role information;
[0115] S208. The first configuration device sends configuration information to the smart terminal to configure the smart terminal.
[0116] The following explanation addresses the above S207:
[0117] The smart terminal can read role information from the target application certificate and determine the access permissions of the first configured device based on the read role information.
[0118] As an example, and not a limiting illustration, a smart terminal can query the ACLE corresponding to the role information in the ACL and determine the access permissions of the first configured device based on the ACLE.
[0119] It should be noted that the smart terminal is pre-configured with several ACLE ACLs, and in this embodiment, the ACLE Subjects attribute is supplemented with role information, such as role ID, as shown in Table 2.
[0120] Table 2
[0121]
[0122] As shown in Table 2, the smart terminal can determine the access permissions of the first configured device from the permissions (Privilege) in the ACLE.
[0123] For example, the smart terminal can verify the target application certificate using the public key in the root certificate of the first configuration device, and execute S207 after the verification is successful.
[0124] For example, the configuration information sent by the first configuration device to the smart terminal can be used to implement access permissions to the smart terminal, such as setting the smart terminal, reading the information of the smart terminal, and controlling the smart terminal to perform corresponding operations.
[0125] Therefore, in this embodiment of the application, the second configuration device can share role information with the first configuration device, thereby enabling the first configuration device to obtain access permissions to the smart terminal through the role information. In this process, only the role information of the second configuration device is transmitted, avoiding the information leakage problem of the Fabric where the first configuration device is located, and the first configuration device only obtains the access permissions represented by the role information, avoiding the expansion of the permissions of the first configuration device.
[0126] In this application embodiment, the role information received by the first configuration device from the second configuration device may include different content. The following describes the implementation of this application when the role information includes different content through several embodiments.
[0127] Example 1: The role information includes a role identifier. Specifically, as follows... Figure 4 As shown, permission sharing can be achieved through at least some of the steps in S10-S27 below.
[0128] S10. The second configuration device sends an authentication request to the first configuration device;
[0129] S11. The first configuration device sends an authentication response to the second configuration device;
[0130] S12. The first signature in the second configuration device verification and authentication response;
[0131] S13. The second configuration device sends role information to the first configuration device;
[0132] S14. The first configuration device requests the CA device to update the application certificate;
[0133] The S15.CA device sends the target application certificate to the first configured device;
[0134] S16. The second configuration device determines whether the root certificate of the first configuration device and the root certificate of the second configuration device are the same;
[0135] S17. The second configuration device sends the root certificate of the first configuration device to the smart terminal;
[0136] S18. The first configuration device sends the target application certificate to the smart terminal;
[0137] S19. The smart terminal verifies the target application certificate using the root certificate of the first configuration device;
[0138] S20. The first configured device establishes a secure connection with the smart terminal;
[0139] S21. The first configuration device authenticates the identity of the smart terminal;
[0140] S22. The smart terminal sends a certificate signing request to the first configuration device;
[0141] S23. The first configuration device sends a certificate signing request for the smart terminal to the CA device;
[0142] The S24.CA device sends a certificate signing response from the smart terminal to the first configured device;
[0143] S25. The first configuration device sends the certificate signature response of the smart terminal to the smart terminal;
[0144] S26. The smart terminal determines the access permissions of the first configuration device based on the role information read from the target application certificate;
[0145] S27. The first configuration device sends configuration information to the smart terminal, which is used to configure the smart terminal.
[0146] In some implementations of Example 1, the role identifier can be roleID (11111111).
[0147] In some implementations of Embodiment 1, S10 to S12 are explained as follows:
[0148] The first configuration device receives an authentication request sent by the second configuration device. The authentication request includes a first random number. Further, the first configuration device sends an authentication response to the second configuration device. The authentication response includes the root certificate of the first configuration device, a first application certificate, and a first signature. The first application certificate is the application certificate of the first configuration device before the update, and the first signature is obtained by the first configuration device using its private key to sign the first random number.
[0149] In some implementations of Embodiment 1, the second configuration device can verify the first application certificate through the root certificate of the first configuration device, and further, verify the first signature through the first application certificate. After the first signature is verified, S13 is executed.
[0150] In some implementations of Embodiment 1, it should be noted regarding S16 that if the root certificates of the second configuration device and the first configuration device are the same, it indicates that they belong to the same Fabric; if the root certificates of the second configuration device and the first configuration device are different, it indicates that they belong to different Fabrics. It should be understood that when the second configuration device and the first configuration device belong to different Fabrics, the second configuration device needs to add the root certificate of the first configuration device to the smart terminal as a trusted root certificate.
[0151] In some implementations of Embodiment 1, S20 to S25 are described as follows:
[0152] After the first configuration device successfully authenticates the smart terminal, the smart terminal sends a certificate signing request to the first configuration device. This certificate signing request requests the CA device corresponding to the first configuration device to sign the smart terminal's certificate. The first configuration device forwards the certificate signing request to the CA device. After signing the smart terminal's certificate, the CA device sends a certificate signing response to the first configuration device. This certificate signing response includes the signed certificate of the terminal device. The first configuration device then forwards either the certificate signing response or the signed certificate to the smart terminal.
[0153] In some implementations of Embodiment 1, the first configuration device requests an update to the application certificate from the CA device to update the first application certificate to the target application certificate. In this embodiment, the first application certificate may be, for example:
[0154]
[0155]
[0156] The updated target application certificate could be, for example:
[0157]
[0158]
[0159] In some implementations of Embodiment 1, S13 to S15, S17 to S19, S26, and S27 are sequentially related to the above. Figure 3 S201 to S208 are similar and will not be described again here.
[0160] In some implementations of Example 1, the execution order of any of steps S18 and S19 to S25 is not required; that is, S18 can be executed before S19, after S25, or during the execution of S19 to S25.
[0161] Example 2: The role information includes a role identifier, the validity period of the role identifier, and a first target signature; wherein, the first target signature is a signature generated by the device sharing the role information using its private key for the role identifier and the validity period of the role identifier. Specifically, as follows... Figure 5 As shown, permission sharing can be achieved through at least some of the steps in S30-S47 below.
[0162] S30. The second configuration device sends a request message to the first configuration device;
[0163] S31. The first configuration device sends a response message to the second configuration device;
[0164] S32. The second configuration device sends role information to the first configuration device;
[0165] S33. The first configuration device requests the CA device to update the application certificate;
[0166] The S34.CA device sends the target application certificate to the first configured device;
[0167] S35. The second configuration device sends the root certificate and public key of the first configuration device to the smart terminal;
[0168] S36. The first configuration device sends the target application certificate to the smart terminal;
[0169] S37. The smart terminal verifies the target application certificate using the root certificate of the first configuration device;
[0170] S38. The smart terminal compares whether the public key read from the target application certificate is consistent with the public key of the first configuration device;
[0171] S39. The smart terminal determines whether the role identifier is within its validity period;
[0172] S40. The first configured device establishes a secure connection with the smart terminal;
[0173] S41. The first configuration device authenticates the identity of the smart terminal;
[0174] S42. The smart terminal sends a certificate signing request to the first configuration device;
[0175] S43. The first configuration device sends a certificate signing request for the smart terminal to the CA device;
[0176] The S44.CA device sends a certificate signing response from the smart terminal to the first configured device;
[0177] S45. The first configuration device sends a certificate signing response from the smart terminal to the smart terminal;
[0178] S46. The smart terminal determines the access permissions of the first configuration device based on the role information read from the target application certificate;
[0179] S47. The first configuration device sends configuration information to the smart terminal, which is used to configure the smart terminal.
[0180] In some implementations of Embodiment 2, the role information can be a type of structured data. For example, if the role ID is 11111111 and the validity period is 03 / 15 / 2021-03 / 16 / 2021, and the signature generated by using the private key of the second configuration device as the role ID and the validity period of the role ID is a89da7f8..., then the role information can be represented as 111111110315202103162021a89da7f8...
[0181] In some implementations of Embodiment 2, S30 and S31 are described as follows:
[0182] The first configuration device receives a request from the second configuration device, which requests to obtain the root certificate and public key of the first configuration device; the first configuration device sends a response to the second configuration device, which includes the root certificate and public key of the first configuration device.
[0183] In some implementations of Embodiment 2, S35 is explained as follows:
[0184] The second configuration device can send the root certificate and public key of the first configuration device to the smart terminal simultaneously, or send the root certificate and public key of the first configuration device separately. For example, the smart terminal sends the root certificate of the first configuration device before S37 and sends the public key of the first configuration device before S38. This embodiment does not require this.
[0185] In some implementations of Embodiment 2, the smart terminal receives the public key of the first configuration device sent by the second configuration device, wherein the second configuration device is a device that shares role information.
[0186] In some implementations of Embodiment 2, S38 is described as follows:
[0187] The smart terminal compares the public key read from the target application certificate with the public key of the first configuration device. If they match, the smart terminal determines the access permissions of the first configuration device based on role information. If they match, step S39 can be executed.
[0188] In some implementations of Embodiment 2, S39 is described as follows:
[0189] If the role identifier is valid, the smart terminal determines the access permissions of the first configuration device based on the role information.
[0190] In some implementations of Embodiment 2, the smart terminal can decrypt the first target signature using the public key of the second configuration device to obtain the role identifier and validity period corresponding to the first target signature, wherein the second configuration device is a device that shares role information; the smart terminal verifies the authenticity of the role identifier and validity period read from the target application certificate based on the role identifier and validity period corresponding to the first target signature; if the role identifier and validity period read from the target application certificate are authentic, the smart terminal determines the access permissions of the first configuration device based on the role information.
[0191] In some implementations of Embodiment 2, the smart terminal can query the second configuration device and obtain the public key of the second configuration device based on the role identifier read from the target application certificate.
[0192] In some implementations of Embodiment 2, the first configuration device requests an update to the application certificate from the CA device to update the first application certificate to the target application certificate. In this embodiment, the target application certificate may be, for example:
[0193]
[0194]
[0195] In some implementations of Embodiment 2, S32 to S34, S36, S37, S46, and S47 are sequentially related to the above. Figure 3 The S201 to S203 and S205 to S208 shown are similar and will not be described again here.
[0196] In some implementations of Embodiment 2, S40 to S45 are sequentially related to the above. Figure 4 S20 to S25 are similar and will not be described again here.
[0197] Example 3: The role information includes a role identifier, an identifier of the first configuration device, the validity period of the role identifier, and a second target signature; wherein, the second target signature is a signature generated by the device sharing the role information using its private key for the role identifier, the identifier of the first configuration device, and the validity period of the role identifier.
[0198] Some implementations of Example 3 also include Figure 5 At least some of the steps shown.
[0199] Combination Figure 5 As shown, in some implementations of Embodiment 3, S30, S31, and S35 are similar to those in Embodiment 2, and will not be described again here.
[0200] In some implementations of Embodiment 3, S38 is explained as follows:
[0201] The smart terminal compares the public key read from the target application certificate with the public key of the first configuration device. If they match, the smart terminal determines the access permissions of the first configuration device based on the role information.
[0202] In some implementations of Embodiment 3, S39 is explained as follows:
[0203] If the role identifier is valid, the smart terminal determines the access permissions of the first configured device based on the role information.
[0204] In some implementations of Embodiment 3, the smart terminal decrypts the second target signature using the public key of the second configuration device to obtain the role identifier, validity period, and identifier of the first configuration device corresponding to the second target signature, wherein the second configuration device is a device that shares role information; the smart terminal verifies the authenticity of the role identifier, validity period, and identifier of the first configuration device read from the target application certificate based on the role identifier, validity period, and identifier of the first configuration device corresponding to the second target signature; if the role identifier, validity period, and identifier of the first configuration device read from the target application certificate are authentic, the smart terminal determines the access permissions of the first configuration device based on the role information.
[0205] In some implementations of Embodiment 3, the smart terminal can query the second configuration device and obtain the public key of the second configuration device based on the role identifier read from the target application certificate.
[0206] In some implementations of Embodiment 3, the smart terminal can decrypt the second target signature using the public key of the second configuration device to obtain the role identifier and / or the identifier of the first configuration device corresponding to the second target signature, wherein the second configuration device is a device that shares role information; the smart terminal compares the role identifier and / or the identifier of the first configuration device corresponding to the second target signature with the role identifier and / or the identifier of the first configuration device read from the target application certificate to see if they are consistent; if they are consistent, the smart terminal determines the access rights of the first configuration device based on the role information.
[0207] In some implementations of Example 3, S32 to S34, S36, S37, S46, and S47 are sequentially related to the above. Figure 3 The steps S201 to S203 and S205 to S208 are similar and will not be described again here.
[0208] In this embodiment, S40 to S45 are sequentially related to the above... Figure 4 S20 to S25 in the illustrated embodiment are similar and will not be described again here.
[0209] Example 4: The role information includes a role identifier, an identifier of a first configuration device, and a third target signature; wherein, the third target signature is a signature generated by the device sharing the role information using its private key for the role identifier and the identifier of the first configuration device.
[0210] In some implementations of Example 4, including Figure 5 The steps shown include at least some of the steps other than S39.
[0211] Combination Figure 5 As shown, in some implementations of Embodiment 4, S30, S31, and S35 are similar to those in Embodiment 2, and will not be described again here.
[0212] In some implementations of Embodiment 4, the smart terminal decrypts the third target signature using the public key of the second configuration device to obtain the role identifier and / or the identifier of the first configuration device corresponding to the third target signature, wherein the second configuration device is the device that shares the role information; the smart terminal compares the role identifier and / or the identifier of the first configuration device corresponding to the third target signature with the role identifier and / or the identifier of the first configuration device read from the target application certificate to see if they are consistent; if they are consistent, the smart terminal determines the access rights of the first configuration device based on the role information.
[0213] In some implementations of Example 4, S38 is described as follows:
[0214] The smart terminal compares the public key read from the target application certificate with the public key of the first configuration device. If they match, the smart terminal determines the access permissions of the first configuration device based on the role information.
[0215] In some implementations of Example 4, S32 to S34, S36, S37, S46, and S47 are sequentially related to the above. Figure 3 The steps S201 to S203 and S205 to S208 are similar and will not be described again here.
[0216] In some implementations of Embodiment 4, S40 to S45 are sequentially related to the above. Figure 4 S20 to S25 in the illustrated embodiment are similar and will not be described again here.
[0217] In some embodiments, role information is added to the NOC certificate of the second configuration device, such as adding a role identifier roleID (11111111), to obtain a NOC certificate with role information. The second configuration device can send the NOC certificate to the first configuration device so that the first configuration device can read the role information of the second configuration device.
[0218] For example, a NOC certificate containing role information could be:
[0219]
[0220]
[0221] Furthermore, after the first configuration device and the second configuration device establish a connection through two-way authentication, the first configuration device queries the ACL for a matching ACLE based on the roleID (11111111) declared in the NOC certificate of the second configuration device, for example:
[0222]
[0223] This ACLE indicates that role ID (11111111) has administrator privileges on the device. Therefore, the first configured device allows the second configured device to perform corresponding operations on the first configured device.
[0224] The above text combined Figures 3 to 5 The method embodiments of this application are described in detail below, in conjunction with... Figures 6 to 10 The present application describes the device embodiments in detail. It should be understood that the device embodiments correspond to the method embodiments, and similar descriptions can be referred to the method embodiments.
[0225] Figure 6 A schematic block diagram of a configuration device 600 according to an embodiment of this application is shown. Figure 6As shown, the configuration device 600 includes:
[0226] The communication unit 610 is used to receive role information, which indicates the role of the device represented by the certificate;
[0227] The communication unit 610 is also used to send first information to the smart terminal, the first information including a target application certificate, and the target application certificate including at least the role information.
[0228] In some embodiments, the target application certificate is used by the smart terminal to determine access permissions to the first configured device.
[0229] In some embodiments, the communication unit 610 is further configured to:
[0230] Send a second message to the Certificate Authority (CA) device, the second message being used to request an update to the application certificate, and the second message including at least the role information;
[0231] Receive third information sent by the CA device, which includes the target application certificate.
[0232] In some embodiments, the second information further includes a first application certificate, which is the application certificate of the first configured device before the update.
[0233] In some embodiments, the role information includes a role identifier.
[0234] In some embodiments, the communication unit 610 is further configured to:
[0235] Receive an authentication request sent by the second configuration device, the authentication request including a first random number;
[0236] An authentication response is sent to the second configuration device. The authentication response includes the root certificate, the first application certificate, and the first signature of the first configuration device. The first application certificate is the application certificate of the first configuration device before the update, and the first signature is obtained by the first configuration device signing the first random number using its private key.
[0237] In some embodiments, the role information includes a role identifier, the validity period of the role identifier, and a first target signature; wherein the first target signature is a signature generated by the device sharing the role information using its private key for the role identifier and the validity period of the role identifier.
[0238] In some embodiments, the role information includes a role identifier, the identifier of the first configuration device, the validity period of the role identifier, and a second target signature; wherein the second target signature is a signature generated by the device sharing the role information using its private key for the role identifier, the identifier of the first configuration device, and the validity period of the role identifier.
[0239] In some embodiments, the role information includes a role identifier, an identifier of the first configuration device, and a third target signature; wherein the third target signature is a signature generated by the device sharing the role information using its private key for the role identifier and the identifier of the first configuration device.
[0240] In some embodiments, the communication unit 610 is further configured to:
[0241] Receive a request message sent by the second configuration device, the request message being used to request the root certificate and public key of the first configuration device;
[0242] Send a response message to the second configuration device, the response message including the root certificate of the first configuration device and the public key of the first configuration device.
[0243] In some embodiments, the communication unit 610 is further configured to:
[0244] Send configuration information to the smart terminal; this configuration information is used to configure the smart terminal.
[0245] It should be understood that the configuration device 600 according to the embodiments of this application may correspond to the first configuration device in the method embodiments of this application, and the above and other operations and / or functions of each unit in the configuration device 600 are respectively for implementing Figures 3 to 5 The corresponding process for the first configured device in the method shown will not be described in detail here for the sake of brevity.
[0246] Figure 7 A schematic block diagram of a smart terminal according to an embodiment of this application is shown. Figure 7 As shown, the smart terminal 700 includes:
[0247] The communication unit 710 is configured to receive first information sent by the first configuration device, the first information including a target application certificate, the target application certificate including role information, the role information being used to indicate the role of the device represented by the certificate;
[0248] The processing unit 720 is used to determine the access permissions of the first configuration device based on the role information.
[0249] In some embodiments, the processing unit 720 is specifically used for:
[0250] Query the Access Control List (ACL) entry corresponding to the role information in the ACL;
[0251] Based on this ACLE, determine the access permissions for the first configured device.
[0252] In some embodiments, the role information includes a role identifier.
[0253] In some embodiments, the role information includes a role identifier, the validity period of the role identifier, and a first target signature; wherein the first target signature is a signature generated by the device sharing the role information using a private key for the role identifier and the validity period of the role identifier.
[0254] In some embodiments, the role information includes a role identifier, the identifier of the first configuration device, the validity period of the role identifier, and a second target signature; wherein, the second target signature is a signature generated by the device analyzing the role information using its private key for the role identifier, the identifier of the first configuration device, and the validity period of the role identifier.
[0255] In some embodiments, the processing unit 720 is specifically used for:
[0256] If the role identifier is valid, the access permissions for the first configuration device are determined based on the role information.
[0257] In some embodiments, the processing unit 720 is specifically used for:
[0258] The first target signature is decrypted using the public key of the second configuration device to obtain the role identifier and validity period corresponding to the first target signature, wherein the second configuration device is the device that shares the role information;
[0259] Based on the role identifier and validity period corresponding to the first target signature, the authenticity of the role identifier and validity period read from the target application certificate is verified;
[0260] If the role identifier and validity period read from the target application certificate are genuine, the access permissions of the first configuration device are determined based on the role information.
[0261] In some embodiments, the processing unit 720 is specifically used for:
[0262] The second target signature is decrypted using the public key of the second configuration device to obtain the role identifier, validity period, and identifier of the first configuration device corresponding to the second target signature. The second configuration device is the device that shares the role information.
[0263] Based on the role identifier, validity period, and first configuration device identifier corresponding to the second target signature, the authenticity of the role identifier, validity period, and first configuration device identifier read from the target application certificate is verified.
[0264] If the role identifier, validity period, and identifier of the first configuration device read from the target application certificate are true, the access permissions of the first configuration device are determined based on the role information.
[0265] In some embodiments, the processing unit 720 is further configured to:
[0266] Based on the role identifier read from the target application certificate, query the second configuration device and obtain the public key of the second configuration device.
[0267] In some embodiments, the processing unit 720 is specifically used for:
[0268] The second target signature is decrypted using the public key of the second configuration device to obtain the role identifier and / or the identifier of the first configuration device corresponding to the second target signature, wherein the second configuration device is the device that shares the role information;
[0269] Compare the role identifier and / or the identifier of the first configuration device corresponding to the second target signature with the role identifier and / or the identifier of the first configuration device read from the target application certificate to see if they are consistent;
[0270] If the information is consistent, the access permissions for the first configured device are determined based on the role information.
[0271] In some embodiments, the role information includes a role identifier, an identifier of the first configuration device, and a third target signature; wherein the third target signature is a signature generated by the device analyzing the role information using its private key for the role identifier and the identifier of the first configuration device.
[0272] In some embodiments, the processing unit 720 is specifically used for:
[0273] The third target signature is decrypted using the public key of the second configuration device to obtain the role identifier and / or the identifier of the first configuration device corresponding to the third target signature, wherein the second configuration device is the device that shares the role information;
[0274] Compare the role identifier and / or the identifier of the first configuration device corresponding to the third target signature with whether they are consistent with the role identifier and / or the identifier of the first configuration device read from the target application certificate;
[0275] If the information is consistent, the access permissions for the first configured device are determined based on the role information.
[0276] In some embodiments, the processing unit 720 is specifically used for:
[0277] Compare whether the public key read from the target application certificate matches the public key of the first configured device;
[0278] If the information is consistent, the access permissions for the first configured device are determined based on the role information.
[0279] In some embodiments, the communication unit 710 is further configured to:
[0280] Receive the public key of the first configuration device sent by the second configuration device, wherein the second configuration device is the device that shares the role information.
[0281] In some embodiments, the processing unit 720 is further configured to:
[0282] The target application certificate is verified using the root certificate of the first configured device.
[0283] In some embodiments, the communication unit 710 is further configured to:
[0284] Receive the root certificate of the first configuration device sent by the second configuration device, wherein the second configuration device is the device that shares the role information.
[0285] It should be understood that the smart terminal 700 according to the embodiments of this application may correspond to the smart terminal in the method embodiments of this application, and the above and other operations and / or functions of each unit in the smart terminal 700 are respectively for implementing Figures 3 to 5 The corresponding processes of the smart terminal in the method shown will not be described in detail here for the sake of brevity.
[0286] Figure 8 A schematic block diagram of a configuration device 800 according to an embodiment of this application is shown. Figure 8 As shown, the configuration device 800 includes:
[0287] The communication unit 810 is used to send role information to the first configuration device, which is used to indicate the role of the device represented by the certificate.
[0288] In some embodiments, the role information includes a role identifier.
[0289] In some embodiments, the communication unit 810 is further configured to send an authentication request to the first configuration device, the authentication request including a first random number; the communication unit 810 is further configured to receive an authentication response sent by the first configuration device, the authentication response including the root certificate, the first application certificate, and the first signature of the first configuration device; wherein the first application certificate is the application certificate of the first configuration device before the update, and the first signature is obtained by the first configuration device signing the first random number using its private key.
[0290] In some embodiments, the role information includes a role identifier, the validity period of the role identifier, and a first target signature; wherein the first target signature is a signature generated by the second configuration device using its private key for the role identifier and the validity period of the role identifier.
[0291] In some embodiments, the role information includes a role identifier, the identifier of the first configuration device, the validity period of the role identifier, and a second target signature; wherein the second target signature is a signature generated by the second configuration device using its private key for the role identifier, the identifier of the first configuration device, and the validity period of the role identifier.
[0292] In some embodiments, the role information includes a role identifier, an identifier of the first configuration device, and a third target signature; wherein the third target signature is a signature generated by the second configuration device using its private key for the role identifier and the identifier of the first configuration device.
[0293] In some embodiments, the communication unit 810 is further configured to:
[0294] The request information sent to the first configuration device is used to request the root certificate and public key of the first configuration device.
[0295] The system receives a response message from the first configuration device, which includes the root certificate and public key of the first configuration device.
[0296] In some embodiments, the communication unit 810 is further configured to:
[0297] Send the public key of the first configuration device to the smart terminal.
[0298] In some embodiments, the communication unit 810 is further configured to:
[0299] Send the root certificate of the first configured device to the smart terminal.
[0300] It should be understood that the configuration device 800 according to the embodiments of this application may correspond to the second configuration device in the method embodiments of this application, and the above and other operations and / or functions of each unit in the configuration device 800 are respectively for implementing Figures 3 to 5 The corresponding process for the second configuration device in the method shown will not be described in detail here for the sake of brevity.
[0301] Figure 9 This is a schematic structural diagram of a communication device provided in an embodiment of this application. Figure 9 The communication device 900 shown includes a processor 910, which can call and run computer programs from memory to implement the methods in the embodiments of this application.
[0302] In some embodiments, such as Figure 9 As shown, the communication device 900 may further include a memory 920. The processor 910 can retrieve and run computer programs from the memory 920 to implement the methods described in this embodiment.
[0303] The memory 920 can be a separate device independent of the processor 910, or it can be integrated into the processor 910.
[0304] In some embodiments, such as Figure 9 As shown, the communication device 900 may also include a transceiver 930, which the processor 910 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.
[0305] The transceiver 930 may include a transmitter and a receiver. The transceiver 930 may further include antennas, and the number of antennas may be one or more.
[0306] In some embodiments, the communication device 900 may specifically be a first configuration device, a second configuration device, or a smart terminal in the embodiments of this application, and the communication device 900 may implement the corresponding processes implemented by the first configuration device, the second configuration device, or the smart terminal in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.
[0307] Figure 10 This is a schematic structural diagram of the device according to an embodiment of this application. Figure 10 The illustrated apparatus 1000 includes a processor 1010, which can call and run computer programs from memory to implement the methods in the embodiments of this application.
[0308] In some embodiments, such as Figure 10 As shown, the device 1000 may further include a memory 1020. The processor 1010 can retrieve and run computer programs from the memory 100 to implement the methods described in the embodiments of this application.
[0309] The memory 1020 can be a separate device independent of the processor 1010, or it can be integrated into the processor 1010.
[0310] In some embodiments, the device 1000 may further include an input interface 1030. The processor 1010 can control the input interface 1030 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips.
[0311] In some embodiments, the device 1000 may further include an output interface 1040. The processor 1010 may control the output interface 1040 to communicate with other devices or chips, specifically, to output information or data to other devices or chips.
[0312] In some embodiments, the device can be applied to the first configuration device, the second configuration device, or the smart terminal in the embodiments of this application, and the device can implement the corresponding processes implemented by the first configuration device, the second configuration device, or the smart terminal in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.
[0313] In some embodiments, the apparatus mentioned in the present application may also be a chip. For example, it may be a system-on-a-chip, a system-on-a-chip, a chip system, or a system-on-a-chip, etc.
[0314] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.
[0315] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0316] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.
[0317] This application also provides a computer-readable storage medium for storing computer programs.
[0318] In some embodiments, the computer-readable storage medium may be applied to the configuration device in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes implemented by the first configuration device in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.
[0319] In some embodiments, the computer-readable storage medium can be applied to the smart terminal in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes implemented by the smart terminal in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.
[0320] In some embodiments, the computer-readable storage medium may be applied to the configuration device in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes implemented by the second configuration device in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.
[0321] This application also provides a computer program product, including computer program instructions.
[0322] In some embodiments, the computer program product can be applied to the configuration device in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the first device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.
[0323] In some embodiments, the computer program product can be applied to the smart terminal in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the smart terminal in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.
[0324] In some embodiments, the computer program product can be applied to the configuration device in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the second device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.
[0325] This application also provides a computer program.
[0326] In some embodiments, the computer program can be applied to the configuration device in the embodiments of this application. When the computer program is run on a computer, it causes the computer to execute the corresponding processes implemented by the first configuration device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.
[0327] In some embodiments, the computer program can be applied to the smart terminal in the embodiments of this application. When the computer program is run on a computer, it causes the computer to execute the corresponding processes implemented by the smart terminal in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.
[0328] In some embodiments, the computer program can be applied to the configuration device in the embodiments of this application. When the computer program is run on a computer, it causes the computer to execute the corresponding processes implemented by the second configuration device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.
[0329] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0330] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0331] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0332] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0333] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0334] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0335] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for wireless communication, characterized in that, include: The first configuration device receives role information, which is used to indicate the role of the device represented by the certificate; The first configuration device sends first information to the smart terminal, the first information including a target application certificate, and the target application certificate including at least the role information; The role information includes a role identifier; The method further includes: The first configuration device receives an authentication request sent by the second configuration device, the authentication request including a first random number; The first configuration device sends an authentication response to the second configuration device. The authentication response includes the root certificate, the first application certificate, and the first signature of the first configuration device. The first application certificate is the application certificate of the first configuration device before the update, and the first signature is obtained by the first configuration device signing the first random number using its private key.
2. The method as described in claim 1, characterized in that, The target application certificate is used by the smart terminal to determine the access permissions of the first configured device.
3. The method as described in claim 1 or 2, characterized in that, The method further includes: The first configuration device sends second information to the certificate authorization CA device, the second information being used to request an update of the application certificate, and the second information including at least the role information; The first configuration device receives third information sent by the CA device, the third information including the target application certificate.
4. The method as described in claim 3, characterized in that, The second information also includes the first application certificate, which is the application certificate of the first configured device before the update.
5. The method according to any one of claims 1 to 4, characterized in that, The role information includes the role identifier, the validity period of the role identifier, and a first target signature; wherein, the first target signature is a signature generated by the device sharing the role information using its private key for the role identifier and the validity period of the role identifier.
6. The method according to any one of claims 1 to 4, characterized in that, The role information includes the role identifier, the identifier of the first configuration device, the validity period of the role identifier, and the second target signature; wherein, the second target signature is a signature generated by the device sharing the role information using its private key for the role identifier, the identifier of the first configuration device, and the validity period of the role identifier.
7. The method according to any one of claims 1 to 4, characterized in that, The role information includes the role identifier, the identifier of the first configuration device, and the third target signature; wherein, the third target signature is a signature generated by the device sharing the role information using its private key for the role identifier and the identifier of the first configuration device.
8. The method according to any one of claims 5 to 7, characterized in that, The method further includes: The first configuration device receives a request message sent by the second configuration device, the request message being used to request the root certificate and public key of the first configuration device; The first configuration device sends a response message to the second configuration device, the response message including the root certificate of the first configuration device and the public key of the first configuration device.
9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: The first configuration device sends configuration information to the smart terminal, and the configuration information is used to configure the smart terminal.
10. A method for wireless communication, characterized in that, include: The second configuration device sends role information to the first configuration device, the role information being used to indicate the role of the device represented by the certificate. The role information includes a role identifier; The second configuration device sends an authentication request to the first configuration device, the authentication request including a first random number; The second configuration device receives an authentication response sent by the first configuration device. The authentication response includes the root certificate, the first application certificate, and the first signature of the first configuration device. The first application certificate is the application certificate of the first configuration device before the update, and the first signature is obtained by the first configuration device signing the first random number using its private key.
11. The method as described in claim 10, characterized in that, The role information includes the role identifier, the validity period of the role identifier, and a first target signature; wherein, the first target signature is a signature generated by the second configuration device using its private key for the role identifier and the validity period of the role identifier.
12. The method as described in claim 10, characterized in that, The role information includes the role identifier, the identifier of the first configuration device, the validity period of the role identifier, and the second target signature; wherein, the second target signature is a signature generated by the second configuration device using its private key for the role identifier, the identifier of the first configuration device, and the validity period of the role identifier.
13. The method as described in claim 10, characterized in that, The role information includes the role identifier, the identifier of the first configuration device, and the third target signature; wherein, the third target signature is a signature generated by the second configuration device using its private key for the role identifier and the identifier of the first configuration device.
14. The method according to any one of claims 11 to 13, characterized in that, The method further includes: The second configuration device sends a request message to the first configuration device, the request message being used to request the root certificate and public key of the first configuration device; The second configuration device receives response information sent by the first configuration device, the response information including the root certificate and public key of the first configuration device.
15. The method according to any one of claims 11 to 14, characterized in that, The method further includes: The second configuration device sends the public key of the first configuration device to the smart terminal.
16. The method according to any one of claims 10 to 15, characterized in that, The method further includes: The second configuration device sends the root certificate of the first configuration device to the smart terminal.
17. A configuration device, characterized in that, The configuration device is a first configuration device, including: A communication unit is used to receive role information, which indicates the role of the device represented by the certificate; The communication unit is also used to send first information to the smart terminal, the first information including a target application certificate, and the target application certificate including at least the role information; The role information includes a role identifier; The communication unit is also used for: Receive an authentication request sent by a second configuration device, the authentication request including a first random number; An authentication response is sent to the second configuration device. The authentication response includes the root certificate, the first application certificate, and the first signature of the first configuration device. The first application certificate is the application certificate of the first configuration device before the update, and the first signature is obtained by the first configuration device signing the first random number with its private key.
18. The device as claimed in claim 17, characterized in that, The target application certificate is used by the smart terminal to determine the access permissions of the first configured device.
19. The device as claimed in claim 17 or 18, characterized in that, The communication unit is also used for: Send a second message to the Certificate Authority (CA) device, the second message being used to request an update of the application certificate, and the second message including at least the role information; Receive third information sent by the CA device, the third information including the target application certificate.
20. The device as claimed in claim 19, characterized in that, The second information also includes the first application certificate, which is the application certificate of the first configured device before the update.
21. The device as claimed in any one of claims 17 to 20, characterized in that, The role information includes the role identifier, the validity period of the role identifier, and a first target signature; wherein, the first target signature is a signature generated by the device sharing the role information using its private key for the role identifier and the validity period of the role identifier.
22. The device according to any one of claims 17 to 20, characterized in that, The role information includes the role identifier, the identifier of the first configuration device, the validity period of the role identifier, and the second target signature; wherein, the second target signature is a signature generated by the device sharing the role information using its private key for the role identifier, the identifier of the first configuration device, and the validity period of the role identifier.
23. The device according to any one of claims 17 to 20, characterized in that, The role information includes the role identifier, the identifier of the first configuration device, and the third target signature; wherein, the third target signature is a signature generated by the device sharing the role information using its private key for the role identifier and the identifier of the first configuration device.
24. The device according to any one of claims 21 to 23, characterized in that, The communication unit is also used for: Receive a request message sent by the second configuration device, the request message being used to request the root certificate and public key of the first configuration device; Send a response message to the second configuration device, the response message including the root certificate of the first configuration device and the public key of the first configuration device.
25. The device as claimed in any one of claims 17 to 24, characterized in that, The communication unit is also used for: Configuration information is sent to the smart terminal, and the configuration information is used to configure the smart terminal.
26. A configuration device, characterized in that, The configuration device is a second configuration device, including: A communication unit is used to send role information to a first configuration device, wherein the role information is used to indicate the role of the device represented by the certificate; The role information includes a role identifier; The communication unit is further configured to send an authentication request to the first configured device, the authentication request including a first random number; The communication unit is further configured to receive an authentication response sent by the first configuration device, the authentication response including the root certificate, the first application certificate, and the first signature of the first configuration device; wherein, the first application certificate is the application certificate of the first configuration device before the update, and the first signature is obtained by the first configuration device signing the first random number using its private key.
27. The device as claimed in claim 26, characterized in that, The role information includes the role identifier, the validity period of the role identifier, and a first target signature; wherein, the first target signature is a signature generated by the second configuration device using its private key for the role identifier and the validity period of the role identifier.
28. The device as claimed in claim 26, characterized in that, The role information includes the role identifier, the identifier of the first configuration device, the validity period of the role identifier, and the second target signature; wherein, the second target signature is a signature generated by the second configuration device using its private key for the role identifier, the identifier of the first configuration device, and the validity period of the role identifier.
29. The device as claimed in claim 26, characterized in that, The role information includes the role identifier, the identifier of the first configuration device, and the third target signature; wherein, the third target signature is a signature generated by the second configuration device using its private key for the role identifier and the identifier of the first configuration device.
30. The device as claimed in any one of claims 27 to 29, characterized in that, The communication unit is also used for: Send a request message to the first configuration device, the request message being used to request the root certificate and public key of the first configuration device; The system receives a response message sent by the first configuration device, the response message including the root certificate and public key of the first configuration device.
31. The device as claimed in any one of claims 27 to 30, characterized in that, The communication unit is also used for: Send the public key of the first configured device to the smart terminal.
32. The device according to any one of claims 26 to 31, characterized in that, The communication unit is also used for: Send the root certificate of the first configured device to the smart terminal.
33. A configuration device, characterized in that, include: A processor and a memory, the memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 1 to 9.
34. A configuration device, characterized in that, include: A processor and a memory, the memory being used to store a computer program, the processor being used to invoke and run the computer program stored in the memory to perform the method as described in any one of claims 10 to 16.
35. A chip, characterized in that, include: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1 to 9.
36. A chip, characterized in that, include: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 10 to 16.
37. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1 to 9.
38. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 10 to 16.
39. A computer program product, characterized in that, It includes computer program instructions that cause a computer to perform the method as described in any one of claims 1 to 9.
40. A computer program product, characterized in that, It includes computer program instructions that cause a computer to perform the method as described in any one of claims 10 to 16.
Citation Information
Patent Citations
Role based access control for connected consumer devices
CN107111697A
Distributed data security sharing method and system based on certificate chain
CN111885154A