Soft bus-based application level interconnection isolation method and terminal

Abstract

The application provides a soft bus-based application-level interconnection isolation method and a terminal. The method comprises the following steps: a first application initiates a group establishment request, establishes a first group, and carries a permission identifier, an accessible device list and an accessible application list in the group establishment request; when receiving a device search request initiated by a second application, obtaining a second application identifier of the second application, screening device information in the device list according to the permission identifier, the second application identifier, the accessible device list and the accessible application list, and returning the screened device information to the second application. The application filters unauthorized applications in the device discovery stage through the multi-dimensional cooperation of the permission identifier, the accessible device list and the accessible application list, blocks unauthorized access from the source, realizes fine-grained isolation of the interconnection channel from device-level sharing to application-level exclusive occupation, guarantees cross-application isolation requirements in high-security scenarios while being compatible with ordinary application experience, and improves the security of distributed interconnection.

Description

Technical Field

[0001] This invention relates to the field of distributed interconnection technology, and in particular to an application-level interconnection isolation method and terminal based on a soft bus. Background Technology

[0002] The open-source HarmonyOS system provides a device mutual trust authentication subsystem and a soft bus subsystem, supporting device-to-device authentication and encrypted communication. However, the related soft bus interconnection capabilities are based on a device-level sharing mechanism. When a first application on a first device establishes a connection with a second device, other applications on the first device can also discover the device and reuse the established communication channel. In high-security scenarios such as financial terminals and police communication systems, this mechanism poses risks of unauthorized access: data leakage risks, as malicious applications can impersonate and exploit channels established by legitimate applications; resource contention issues, as unauthorized applications can occupy dedicated bandwidth resources; and auditing difficulties, as the system cannot trace which application initiated the communication. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide an application-level interconnection isolation method and terminal based on a soft bus, which can refine the interconnection channel between devices from device-level sharing to application-level exclusive use, thereby realizing application-level security isolation of interconnection resources.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: An application-level interconnection isolation method based on a soft bus, characterized in that it includes: The first application initiates a group creation request to create a first group. The group creation request carries a permission identifier, a list of accessible devices, and a list of accessible applications. When a device search request initiated by a second application is received, the second application identifier of the second application is obtained, and the device information in the device list is filtered according to the permission identifier, the accessible device list of the second application identifier, and the accessible application list, and the filtered device information is returned to the second application.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An application-level interconnect isolation terminal based on a soft bus includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the computer program to implement the various steps of the aforementioned application-level interconnect isolation method based on a soft bus.

[0006] The beneficial effects of this invention are as follows: By carrying a permission identifier, a list of accessible devices, and a list of accessible applications when the first application initiates a group creation request, a first group is established, providing a calculable data foundation for subsequent device search and filtering; when the second application initiates a device search request, by obtaining the second application identifier and matching it with the permission identifier, the list of accessible devices, and the list of accessible applications, forced filtering is performed on the device list, preventing unauthorized applications from obtaining device information in the target group during the device discovery phase, thus blocking the possibility of unauthorized access from the source; through the combined use of the permission identifier, the list of accessible devices, and the list of accessible applications, the permission identifier is used to indicate the access permission type of the first group, the list of accessible devices is used to record devices allowed to be accessed by the first group, and the list of accessible applications is used to record applications authorized to access the first group, the configuration and use of these three achieves fine-grained permission control for device discovery requests; this invention implements application-level permission filtering during the device discovery phase, realizing fine-grained isolation of the interconnection channel from device-level sharing to application-level exclusivity, solving the technical problem of unauthorized access across applications on the same device in high-security scenarios, and improving the security of distributed interconnection. Attached Figure Description

[0007] Figure 1 This is a flowchart illustrating an application-level interconnection isolation method based on a soft bus according to an embodiment of the present invention; Figure 2 This is a system architecture diagram of an application-level interconnection isolation method based on a soft bus according to an embodiment of the present invention; Figure 3 This is a timing diagram of the device interconnection process of an application-level interconnection isolation method based on a soft bus according to an embodiment of the present invention; Figure 4 This is a schematic diagram of an application-level interconnection isolation terminal based on a soft bus according to an embodiment of the present invention. Detailed Implementation

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] In existing technologies, the open-source HarmonyOS provides a device mutual trust authentication subsystem and a soft bus subsystem, supporting inter-device authentication and encrypted communication. These solutions are primarily applied to multi-device collaboration scenarios in the consumer electronics field, such as file sharing and audio / video streaming. However, these technologies still suffer from the following problems: First, the soft bus interconnection capability is based on a device-level sharing mechanism. Once the first application establishes a connection with the second device, other applications on the same device can also discover the device and reuse the established communication channel, resulting in insufficient security isolation between applications. Second, malicious applications can impersonate and exploit payment channels established by legitimate applications, leading to unauthorized access to sensitive data and the risk of data leakage. Third, the system cannot trace which application initiated a specific communication. Once a security incident occurs, it is difficult to determine responsibility and conduct post-incident accountability, posing serious security risks to high-security scenarios such as financial terminals, police communication systems, and industrial control.

[0010] To at least address the aforementioned issues, the first application initiates a group creation request, establishing a first group. This request includes a permission identifier, a list of accessible devices, and a list of accessible applications. Upon receiving a device search request from the second application, the application retrieves its second application identifier and filters the device information in the list based on the permission identifier, the second application identifier, the list of accessible devices, and the list of accessible applications. The filtered device information is then returned to the second application. This approach, through multi-dimensional collaboration of permission identifiers, the list of accessible devices, and the list of accessible applications, filters unauthorized applications during the device discovery phase, blocking unauthorized access at the source. It achieves fine-grained isolation of the interconnection channel, from device-level sharing to application-level exclusivity, ensuring cross-application isolation requirements in high-security scenarios while maintaining compatibility with ordinary application experiences, thus enhancing the security of distributed interconnections.

[0011] The following details an application-level interconnection isolation method based on a soft bus according to the present invention. Please refer to [link / reference]. Figure 1 The method 100 includes steps 110 to 120.

[0012] Step 110: The first application initiates a group creation request to create the first group. The group creation request carries the permission identifier, the list of accessible devices, and the list of accessible applications.

[0013] For example, in a financial payment scenario, a payment application on a device initiates a group creation request as the first application, and the request carries permission identifiers, a list of accessible devices, and a list of accessible applications.

[0014] Step 120: When a device search request initiated by the second application is received, the second application identifier of the second application is obtained, and the device information in the device list is filtered according to the permission identifier, the second application identifier, the list of accessible devices, and the list of accessible applications. The filtered device information is then returned to the second application.

[0015] For example, in common cross-device collaboration scenarios, the first application on the first device initiates a group creation request as the group creator, specifying the target device as an accessible device and adding its own application identifier to the accessible application list. When the second application on the second device (i.e., a same-origin instance of the first application on another device) initiates a device lookup request, the system obtains the application identifier of that application and filters the device information in the device list based on the permission identifier, application identifier, accessible device list, and accessible application list. If the second application's identifier belongs to the accessible application list, the target device's device information is added to the return list and returned to the second application, enabling the application instance on the second device to discover and connect to the target device, completing cross-device communication and data transmission, and achieving collaborative execution of distributed tasks. This approach not only supports isolation between different applications on a unified device but also supports interconnection between same-origin application instances on different devices, meeting the diverse communication needs between applications in distributed scenarios while maintaining application-level isolation security constraints.

[0016] As described above, when the first application initiates a group creation request, it carries a permission identifier, a list of accessible devices, and a list of accessible applications. This clearly defines the permission boundaries for accessing the device list from the very beginning of group creation, providing a multi-dimensional data foundation for permission verification during the subsequent device discovery phase. When the second application initiates a device search request, the device list is forcibly filtered by obtaining the second application's identifier and combining it with the above three dimensions, preventing unauthorized applications from obtaining device information during the device discovery phase and blocking unauthorized access at the source. When the permission identifier is public, it is compatible with the experience of ordinary applications; when the permission identifier is private, only authorized applications are allowed to access it. This invention implements application-level and device-level dual filtering during the device discovery phase, achieving fine-grained isolation of the interconnection channel from device-level sharing to application-level exclusivity. This solves the technical problem of unauthorized access across applications on the same device in high-security scenarios and improves the security of distributed interconnection.

[0017] In one alternative implementation, step 110 establishes a first group, including steps 111 and 112.

[0018] Step 111: Establish group association information for the first group based on the permission identifier, the list of accessible devices, and the list of accessible applications.

[0019] For example, after receiving a group creation request initiated by the first application, the device mutual trust authentication subsystem parses the permission identifier, the list of accessible devices, and the list of accessible applications from the request, and records the above information in the group entry to form the group association information of the first group. Step 112: Persistently store the group association information.

[0020] For example, the device mutual trust authentication subsystem persistently stores the group association information established in step 111 in the local storage medium of the first device. Each device in the distributed network independently maintains its own group association information; that is, the first device stores the group association information it created, and other devices store their own group association information. The group association information between the devices is independent and does not interfere with each other.

[0021] As described above, by associating and recording permission identifiers, accessible device lists, and accessible application lists in group association information and persistently storing them locally, and with each device independently maintaining its own group association information, the permission boundaries of the device access list are clearly defined when the group is created. This provides a complete and reliable data foundation for permission verification in the subsequent device discovery phase, ensuring that permission verification can be performed independently and accurately based on the persistent group association information of the device, thus avoiding dependence on centralized storage.

[0022] In one optional implementation, step 120 filters the device information in the device list based on the permission identifier, the second application identifier, the list of accessible devices, and the list of accessible applications, including steps 121 to 124.

[0023] Step 121: Traverse the device list.

[0024] For example, after the second application initiates a device search request, the system obtains a list of online devices in the distributed network and iterates through each device record in the list in turn.

[0025] Step 122: For each candidate device in the device list, query the target group that includes the candidate device in the accessible device list, and obtain the permission identifier, accessible device list, and accessible application list of the target group.

[0026] For example, for the candidate device currently being traversed, the system queries the list of accessible devices containing the candidate device in the stored group association information. If the target group is found, the system obtains the permission identifier, list of accessible devices, and list of accessible applications corresponding to the target group. If no target group containing the candidate device is found, the system determines that the candidate device does not belong to any authorized group and discards the device information of the candidate device.

[0027] Step 123: If the permission identifier is public, add the device information of the candidate device to the returned list.

[0028] For example, if the permission identifier obtained in step 122 is public, it means that the group to which the candidate device belongs allows any application to discover and connect, and the device information of the candidate device is added to the returned list. In this case, neither the list of accessible devices nor the list of accessible applications takes effect. That is, in public mode, the existing device-level sharing mechanism is maintained, and any application can discover and connect to devices in the group without application-level identity verification, so as to ensure that the distributed experience in ordinary application scenarios is not affected.

[0029] Step 124: If the permission identifier is private, determine whether the second application identifier belongs to the list of accessible applications. If so, add the device information of the candidate device to the returned list; otherwise, discard the device information of the candidate device.

[0030] For example, if the permission identifier obtained in step 122 is private, it means that the group to which the candidate device belongs only allows authorized applications to access it. Then, it is further determined whether the second application identifier belongs to the list of accessible applications of the group. If it does, the device information of the candidate device is added to the returned list. If it does not, the device information of the candidate device is discarded.

[0031] As described above, by traversing the device list and querying the permission identifier of the target group to which each candidate device belongs, when the permission identifier is public, it is directly added to the returned list. When the permission identifier is private, it further verifies whether the second application identifier belongs to the list of accessible applications. This achieves multi-dimensional and refined filtering of the device list, so that unauthorized applications are filtered one by one during the device discovery stage and cannot obtain device information from the list of accessible devices, thus blocking unauthorized access from the source.

[0032] In an alternative implementation, step 122 queries the target group that includes candidate devices in the list of accessible devices, including steps 1221 and 1222.

[0033] Step 1221: Obtain the device identifier of the candidate device.

[0034] For example, for the candidate device currently being traversed, the system obtains the device identifier of the candidate device, which is used to uniquely identify the device in the distributed network.

[0035] Step 1222: Based on the device identifier of the candidate device, retrieve the matching device identifier from the list of accessible devices.

[0036] For example, the system compares the device identifier of the candidate device obtained in step 1221 with the device identifiers in the accessible device list of each group in the stored group association information one by one; if a matching device identifier is found, it is determined that the candidate device exists in the accessible device list of the group, and the group is selected as the target group; if no matching device identifier is found, it is determined that the candidate device does not exist in the accessible device list of any group.

[0037] As described above, by obtaining the device identifier of the candidate device and retrieving the matching device identifier in the list of accessible devices, the target group to which the candidate device belongs is quickly located. This provides a foundation for subsequently obtaining the permission identifier, list of accessible devices, and list of accessible applications for the target group, ensuring the accurate execution of the device screening process.

[0038] In one optional implementation, the accessible application list includes an application identifier and an authorized application list. The application identifier is the application identifier of the creator of the first group, and the authorized application list records the application identifiers of other applications in the first group that the first application authorizes to use. Step 124 determines whether the second application identifier belongs to the accessible application list, including steps 1241 to 1246.

[0039] Step 1241: Determine whether the second application identifier is equal to the application identifier.

[0040] For example, the system obtains the second application identifier of the second application and the application identifier of the target group in the list of accessible applications, compares the two, and determines whether the second application identifier is equal to the application identifier.

[0041] Step 1242: If the value is equal to the application identifier, then the second application identifier is determined to belong to the list of accessible applications.

[0042] For example, the system obtains the second application identifier of the second application and the application identifier of the target group in the list of accessible applications, compares the two, and determines whether the second application identifier is equal to the application identifier.

[0043] Step 1243: If it is not equal to the application identifier, then continue to determine whether the second application identifier belongs to the authorized application list.

[0044] For example, if the result of the determination in step 1241 is not equal, it means that the second application is not the creator of the first group. Then the system continues to determine whether the second application identifier belongs to any application identifier in the authorized application list, so as to determine whether the second application has been authorized by the creator to use the first group.

[0045] Step 1244: If it belongs to the authorized application list, then determine that the second application identifier belongs to the accessible application list.

[0046] For example, if the determination result in step 1243 is "belongs to", it means that the second application has been authorized by the creator to use the first group. The system determines that the second application identifier belongs to the list of accessible applications, allowing the second application to discover and connect to devices in the target group.

[0047] Step 1245: If it does not belong to the authorized application list, then determine that the second application identifier does not belong to the accessible application list.

[0048] For example, if the determination result in step 1243 is "not belonging", it means that the second application is neither the creator nor authorized to use the first group. The system determines that the second application identifier does not belong to the list of accessible applications, discards the device information of the candidate device, and the second application cannot discover and connect to the device in the target group.

[0049] As described above, by first determining whether the second application identifier is equal to the creator's application identifier, and then determining whether it belongs to the authorized application list, a two-step verification mechanism of "first verifying the creator's identity, and then verifying the authorized identity" is formed. This ensures that only the creator and other authorized applications can discover and connect to the devices in the first group, effectively preventing unauthorized applications from accessing the devices without authorization and improving the security and accuracy of group access control.

[0050] In an alternative implementation, method 100 further includes steps 130 and 131.

[0051] Step 130: Receive the authorization request sent by the first application, the authorization request carrying the target application identifier.

[0052] For example, when the creator of the first group (i.e. the first application) needs to authorize other applications on the same device to use the first group, the first application sends an authorization request to the system. The authorization request carries the target application identifier, which is the application identifier of the other application authorized to use the first group.

[0053] Step 131: In response to the authorization request, add the target application identifier to the list of accessible applications.

[0054] For example, after receiving an authorization request from the first application, the system parses out the target application identifier carried within it and adds the target application identifier to the authorized application list within the accessible application list of the first group. Once added, the authorized target application will be determined to belong to the accessible application list during the subsequent device search phase, thus having the right to discover and connect to devices in the first group.

[0055] As described above, by receiving the authorization request sent by the first application and adding the target application identifier to the list of accessible applications, the creator can dynamically manage the group's access permissions, enabling the first group to authorize other applications to use it as needed. This ensures the security of group access and provides flexible authorization extension capabilities.

[0056] In an alternative implementation, the method 100 further includes steps 140 and 141.

[0057] Step 140: When a request to establish a data transmission channel with the target device in the device information is received from the second application, the group association information of the target device's group is matched with the identifier of the second application to generate a verification result.

[0058] For example, after the second application obtains device information during the device discovery phase, it selects the target device and initiates a data transmission channel establishment request. Before establishing the session channel, the system sends an authorization verification request to the device mutual trust authentication subsystem. The authorization verification request carries the second application identifier and the target device's device identifier. The device mutual trust authentication subsystem matches and verifies the second application identifier based on the group association information of the target device's group and generates a verification result.

[0059] Step 141: When the verification result is a verification failure, refuse to establish a data transmission channel with the device corresponding to the device information.

[0060] For example, if the verification result returned by the device mutual trust authentication subsystem in step 140 is a verification failure, the soft bus subsystem refuses to establish a data transmission channel with the target device and does not send any data packets to the target device, thereby ensuring that the establishment of any data transmission channel is subject to application-level authorization verification.

[0061] As described above, by refusing to establish a data transmission channel when verification fails, a second line of defense is added at the session layer. Even if an application bypasses the device discovery interface and attempts to connect directly, it will still be blocked, ensuring that the establishment of any data transmission channel is subject to application-level authorization verification. This effectively prevents applications from bypassing the query interface and attempting to connect directly to IP (Internet Protocol) addresses through illegal means.

[0062] In one optional implementation, step 140 generates a verification result by matching the group association information of the target device's group with the second application identifier, including steps 1401 to 1403.

[0063] Step 1401: Query the permission identifier in the group association information of the group to which the target device belongs.

[0064] For example, after receiving a permission verification request, the device mutual trust authentication subsystem queries the locally stored group association information for the group to which the target device belongs, based on the device identifier of the target device carried in the permission verification request, and obtains the permission identifier from the group association information. If the target device is not associated with any group, the verification is deemed to have failed.

[0065] Step 1402: When the permission identifier is public, generate a verification result that has passed the verification.

[0066] For example, if the permission identifier found in step 1401 is public, it means that the group to which the target device belongs allows any application to discover and connect. In this case, the device mutual trust authentication subsystem directly generates a verification result that has passed the verification and returns it to the soft bus subsystem, allowing the second application to establish a data transmission channel with the target device.

[0067] Step 1403: When the permission identifier is private, determine whether the second application identifier belongs to the list of accessible applications of the group to which the target device belongs. If so, generate a verification result that passes the verification; otherwise, generate a verification result that fails the verification.

[0068] For example, if the permission identifier queried in step 1401 is private, it means that the group to which the target device belongs only allows authorized applications to discover and connect. The device mutual trust authentication subsystem then further determines whether the second application identifier belongs to the accessible application list of the group to which the target device belongs. If the second application identifier belongs to either the belonging application identifier in the accessible application list or any application identifier in the authorized application list, it indicates that the second application is an application authorized by the group creator or the created entity to use the group. In this case, a verification result is generated indicating that the verification has passed, allowing the second application to establish a data transmission channel with the target device. If the second application identifier belongs neither to the belonging application identifier nor to the authorized application list, it indicates that the second application is neither the creator nor authorized. In this case, a verification result is generated indicating that the verification has failed, and the establishment of a data transmission channel between the second application and the target device is rejected.

[0069] As described above, by querying the permission identifier of the target device's group before establishing the data transmission channel, and directly allowing access when the permission identifier is public, and further verifying whether the second application identifier belongs to the list of accessible applications when the permission identifier is private, a second permission verification at the session layer is achieved. On the basis of the mandatory filtering in the device discovery stage, a second line of defense is added at the session layer to ensure that only authorized applications can establish a data transmission channel with the target device, effectively preventing applications from bypassing the device discovery interface and directly attempting to connect to the target device's IP address through illegal means.

[0070] In one alternative implementation, after step 110 establishes the first group, step 113 is also included.

[0071] Step 113: Send a group establishment broadcast via the status bus. The group establishment broadcast is used to notify other devices in the distributed network that the first group has been established.

[0072] For example, after the device mutual trust authentication subsystem completes the creation and persistent storage of the group association information of the first group, it sends a group establishment broadcast to other devices in the distributed network through the status bus. The broadcast message carries information such as the group identifier of the first group to notify other devices that the first group has been established and can be discovered.

[0073] As described above, sending a group establishment broadcast via the status bus enables other devices in the distributed network to promptly perceive the establishment status of the first group. This provides a prerequisite for other devices to obtain the device information of the first group when initiating a device search request, thus ensuring the real-time performance and effectiveness of the group discovery mechanism.

[0074] Please refer to Figure 2 , Figure 2 This is a system architecture diagram of an application-level interconnection isolation method based on a soft bus, provided in an embodiment of the present invention.

[0075] The interconnected software layer 201 includes application A, application B, and application C. Application A is the application that creates the private channel of application A, i.e., the first application; application B is an application that cannot access the private channel of application A, i.e., an unauthorized application; and application C is an AllowApp belonging to the private channel of application A, i.e., an application authorized by the first application to use this private channel.

[0076] The open-source HarmonyOS system layer 202 includes a distributed device management service (DeviceManager), a device mutual trust and authentication subsystem (HiChain), and a distributed soft bus subsystem (SoftBus).

[0077] The distributed device management service, as the core of distributed interconnection management, is responsible for receiving group creation requests and device search requests initiated by applications, maintaining group association information, and performing mandatory filtering on the device list. The device mutual trust authentication subsystem, acting as the root of trust, is responsible for establishing and persistently storing group association information, as well as performing permission verification. The distributed soft bus subsystem, as the underlying communication channel, establishes an encrypted transmission channel based on the root of trust provided by the device mutual trust authentication subsystem.

[0078] Taking the creation of a private interconnection channel by a payment application in a financial payment terminal as an example: Application A (creating the application A private channel) initiates a group establishment request through the distributed device management service to establish a private group. The distributed device management service calls the device mutual trust authentication subsystem to establish group association information (including permission identifier, list of accessible devices, and list of accessible applications) and persists it. When application B (unable to access application A's private channel) on the same terminal initiates a device search request, the distributed device management service filters the device list based on the permission identifier, application B's application identifier, list of accessible devices, and list of accessible applications, preventing application B from obtaining device information in the private channel. When application C (belonging to the AllowApp of application A's private channel) initiates a device search request, because its application identifier belongs to the list of accessible applications, the distributed device management service adds its device information to the returned list, allowing application C to access the private channel created by application A normally. When application A or application C selects a target device and initiates a data transmission channel establishment request, the distributed soft bus subsystem calls the device mutual trust authentication subsystem to perform a secondary permission verification before initiating a handshake with the target device. Only after the verification is passed can the data transmission channel be established.

[0079] Through the above system architecture and system operation process, this invention achieves end-to-end application-level isolation from group creation and device discovery to session establishment by deploying distributed device management services, device mutual trust authentication subsystems and distributed soft bus subsystems in the open-source HarmonyOS system. This prevents unauthorized applications from obtaining device information during the device discovery phase, blocking unauthorized access at the source, and adds a second line of defense at the session layer, effectively solving the technical problem of unauthorized access across applications on the same device under the device-level sharing mechanism.

[0080] Please refer to Figure 3 The following describes in detail an application embodiment of the application-level interconnection isolation method based on a soft bus in this invention. This application can apply the above solution to high-security scenarios requiring application-level isolation of distributed interconnection channels, particularly in distributed terminal application fields such as financial payment and industrial control, where data security and access permissions are strictly required. Taking the creation of a private interconnection channel in a financial payment terminal as an example, the steps include: S301, Application A on Device 1 requests to create a P2P group, visibilityMode=APP_PRIVATE.

[0081] The payment application, acting as application A, initiates a group creation request. This request includes a visibility policy indication, set to APP_PRIVATE (private mode), indicating that the group is a private group for the application and can only be accessed by authorized applications. This is equivalent to step 110 above.

[0082] S302. The DM service receives the request and persists the metadata ownerAppId=A:allowedApps=[A].

[0083] After receiving a group establishment request from application A, the Distributed Device Management Service (DM Service) calls the Device Mutual Trust Authentication Subsystem. Based on the visibility policy indication information, it determines that the permission identifier is private and generates group association information. This information records the owner application identifier (ownerAppId) as the application identifier of application A. The list of accessible applications initially includes application A's own application identifier (allowedApps=[A]), and this group association information is persistently stored locally. This is equivalent to steps 111 to 112 above.

[0084] S303, Send device broadcast via soft bus.

[0085] After the group association information is persistently stored, device 1 sends a group establishment broadcast to other devices in the distributed network through the distributed soft bus subsystem, notifying other devices that the first group has been established and can be discovered. This is equivalent to step 113 above.

[0086] S304, Application A on device 2 requests to discover the list of devices.

[0087] Application A on device 2 initiates a device search request to discover a list of connectable devices in the distributed network. This request carries application A's application identifier for subsequent permission verification. This is equivalent to step 120 above.

[0088] S305, the DM service receives a device discovery request and finds the broadcast sent by device A.

[0089] After receiving the device search request initiated by application A on device 2, the DM service searches for broadcast information of devices that have established groups in the distributed network. It finds the group establishment broadcast sent by device 1 via the soft bus and obtains the group information of device 1. This is equivalent to the device discovery process after "receiving the device search request initiated by the second application" in step 120 above.

[0090] S306, DM query group attribute = PRIVATE, verify A belongs to ownerAppId.

[0091] The DM service queries the group association information of the group to which device 1 belongs, determines that the group's permission identifier is PRIVATE, and further verifies whether the application identifier of application A is equal to the owner application identifier (ownerAppId) of this group or belongs to the allowed applications list (allowedApps). Since the application identifier of application A is equal to the ownerAppId, the verification passes. This is equivalent to steps 122 to 124 above.

[0092] S307. Return a device list containing information about device 1 to application A (if the requesting application is not equal to ownerAppId and does not belong to allowedApps, then device information is not returned to the requesting application). The user selects device 1 from the list of discovered devices and initiates a connection.

[0093] After successful verification, the DM service adds device 1's device information to the return list and returns a list of devices containing device 1's information to application A. Application A selects device 1 from the discovered device list and initiates a data transmission channel establishment request. If the requesting application is not equal to ownerAppId and does not belong to allowedApps, device information is not returned to the requesting application. This is equivalent to steps 123 to 124 above.

[0094] S308, DM queries the group attribute = PRIVATE, verifies that A belongs to ownerAppId (if the requesting application is not equal to ownerAppId and does not belong to allowedApps, then device information will not be returned to the requesting application), creates a device interconnection session channel through the soft bus, and returns the result upon successful connection.

[0095] Before the session is established, the DM service queries the group attributes again to verify whether the application ID of application A, which initiated the connection request, belongs to the list of accessible applications in the group. If the verification passes, an encrypted data transmission channel is established between device 2 and device 1 via the distributed soft bus subsystem. Upon successful connection, a result is returned. If the requesting application is not equal to ownerAppId and does not belong to allowedApps, the connection is rejected. This is equivalent to steps 140 to 141 above.

[0096] Through the above application examples, this invention effectively solves the technical problems of data leakage, resource contention, and auditing difficulties caused by unauthorized cross-application access on the same device under a device-level sharing mechanism. Since the permission identifier and list of accessible applications are clearly defined when the group is created, mandatory filtering is performed during the device discovery phase. Unauthorized applications cannot obtain device information during this phase, blocking unauthorized access at the source. Simultaneously, a secondary permission verification is performed before session establishment, so even if an application attempts to bypass the device discovery interface and connect directly, it will still be blocked. In this way, reliable, efficient, and fine-grained application-level security isolation is provided for distributed interconnection in high-security scenarios such as financial terminals and police communication systems.

[0097] Please refer to Figure 4The present invention also provides an application-level interconnection isolation terminal 400 based on a soft bus, including a memory 401, a processor 402, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of the application-level interconnection isolation method based on a soft bus as described above.

[0098] In summary, this invention provides an application-level interconnection isolation method and terminal based on a soft bus.

[0099] First, when the first application initiates a group creation request, it carries a permission identifier, a list of accessible devices, and a list of accessible applications. This clearly defines the group's access permission type, the range of allowed devices, and the range of allowed applications, establishing the permission boundaries of the device access list from the very beginning of group creation. Second, when the second application initiates a device search request, the second application's identifier is obtained and, combined with the above three dimensions, the device list is forcibly filtered, preventing unauthorized applications from obtaining device information during the device discovery phase and blocking unauthorized access at the source. Third, when the permission identifier is public, the existing device-level sharing mechanism is maintained to ensure a distributed experience for ordinary application scenarios; when the permission identifier is private, the second application's identifier is further verified to ensure it belongs to the list of accessible applications, achieving application-level fine-grained isolation. Furthermore, a second permission verification is performed before the data transmission channel is established. Even if an application attempts to bypass the device discovery interface and connect directly, it will still be blocked, ensuring that the establishment of any data transmission channel undergoes application-level authorization verification.

[0100] This invention effectively solves the technical problems of data leakage, resource contention, and auditing difficulties caused by device-level sharing in related soft bus interconnection mechanisms. It realizes fine-grained isolation of interconnection channels from device-level sharing to application-level exclusive use. While being compatible with the distributed experience of ordinary applications, it ensures the security isolation requirements of cross-application devices in high-security scenarios, providing reliable protection for distributed interconnection in high-security scenarios such as financial terminals and industrial control.

[0101] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An application-level interconnection isolation method based on a soft bus, characterized in that, include: The first application initiates a group creation request to create the first group. The group creation request carries a permission identifier, a list of accessible devices, and a list of accessible applications. When a device search request initiated by a second application is received, the second application identifier of the second application is obtained. The device information in the device list is filtered according to the permission identifier, the second application identifier, the list of accessible devices, and the list of accessible applications. The filtered device information is then returned to the second application.

2. The application-level interconnection isolation method based on a soft bus according to claim 1, characterized in that, The establishment of the first group includes: The group association information of the first group is established based on the permission identifier, the list of accessible devices, and the list of accessible applications; The group association information is persistently stored.

3. The application-level interconnection isolation method based on a soft bus according to claim 1, characterized in that, The step of filtering device information in the device list based on the permission identifier, the second application identifier, the list of accessible devices, and the list of accessible applications includes: Iterate through the list of devices; For each candidate device in the device list, query the target group that includes the candidate device in the accessible device list, and obtain the permission identifier, the accessible device list, and the accessible application list of the target group; If the permission identifier is public, then the device information of the candidate device is added to the return list; If the permission identifier is private, then determine whether the second application identifier belongs to the list of accessible applications. If so, add the device information of the candidate device to the returned list; otherwise, discard the device information of the candidate device.

4. The application-level interconnection isolation method based on a soft bus according to claim 3, characterized in that, The query of the target group of the candidate devices in the list of accessible devices includes: Obtain the device identifier of the candidate device; Based on the device identifier of the candidate device, a matching device identifier is retrieved from the list of accessible devices.

5. The application-level interconnection isolation method based on a soft bus according to claim 3, characterized in that, The list of accessible applications includes an application identifier and a list of authorized applications. The application identifier is the application identifier of the creator of the first group, and the list of authorized applications records the application identifiers of other applications in the first group that the first application authorizes to use. The step of determining whether the second application identifier belongs to the list of accessible applications includes: Determine whether the second application identifier is equal to the corresponding application identifier; If it is equal to the application identifier, then the second application identifier is determined to belong to the list of accessible applications; If it is not equal to the application identifier, then continue to determine whether the second application identifier belongs to the authorized application list; If it belongs to the authorized application list, then the second application identifier is determined to belong to the accessible application list; If it does not belong to the authorized application list, then it is determined that the second application identifier does not belong to the accessible application list.

6. The application-level interconnection isolation method based on a soft bus according to claim 1, characterized in that, Also includes: Receive an authorization request sent by the first application, wherein the authorization request carries the target application identifier; In response to the authorization request, the target application identifier is added to the list of accessible applications.

7. The application-level interconnection isolation method based on a soft bus according to claim 6, characterized in that, Also includes: When a request is received from the second application to establish a data transmission channel with the target device in the device information, the group association information of the target device's group is matched with the identifier of the second application to generate a verification result; When the verification result is a verification failure, the establishment of a data transmission channel with the device corresponding to the device information is refused.

8. The application-level interconnection isolation method based on a soft bus according to claim 7, characterized in that, The step of generating a verification result by matching the group association information of the target device's group with the second application identifier includes: Query the permission identifier in the group association information of the group to which the target device belongs; When the permission identifier is public, a verification result that passes the verification is generated; When the permission identifier is private, determine whether the second application identifier belongs to the list of accessible applications of the group to which the target device belongs. If so, generate a verification result that passes the verification; otherwise, generate a verification result that fails the verification.

9. The application-level interconnection isolation method based on a soft bus according to claim 1, characterized in that, After establishing the first group, the process also includes: A group establishment broadcast is sent via the status bus to notify other devices in the distributed network that the first group has been established.

10. An application-level interconnect isolation terminal based on a soft bus, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements each step of the application-level interconnect isolation method based on a soft bus as described in any one of claims 1 to 9.

Images