Four-dimensional dynamic coupling communication method of master-slave architecture secure collaborative telephone

Abstract

The application discloses a four-dimensional dynamic coupling communication method of a master-slave architecture secret cooperative telephone, which comprises the following steps: registering a slave machine through a distributed trusted chain, and pre-setting a root key by fragmentation, completing identity filing, certificate issuing and key storage; performing chain type bidirectional dynamic access authentication, realizing cross authentication and permission initialization of boot-up access; establishing a dynamic encryption communication link of point-to-point secret-related gradient binding between internal slaves; constructing a double-domain isolated encryption outgoing link from the slave to an external line, and external line incoming intelligent identification and switching; after communication ends, the master destroys the key and performs full-process audit and evidence storage, realizing a life cycle closed loop. Through the distributed trusted chain and dynamic key management, in combination with secret-related gradient encryption and double-domain isolation technology, the application ensures full-process encryption, instant key destruction, full-process audit and evidence storage, and builds a safety closed loop, effectively improving the security and controllability of secret communication.

Description

Technical Field

[0001] This invention relates to the field of secure communication technology, and more specifically to a four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone. Background Technology

[0002] Existing mainstream master-slave telephone exchange systems, national cryptographically encrypted telephones, and automatic call transfer solutions with intelligent recognition, while achieving basic functions such as multi-terminal collaborative call management, end-to-end anti-eavesdropping of voice messages, and intelligent call transfer, and addressing basic communication and collaboration needs in office scenarios, generally suffer from the common industry pain point of failing to balance high-level security protection with efficient collaborative communication. Existing solutions all use the host as the sole trusted root of the system, resulting in a single point of security bottleneck where the entire system collapses if the host is compromised or tampered with. Furthermore, the static fixed key design, where a single key negotiation is required throughout the call, cannot adapt to scenarios where the confidentiality level of the call content changes dynamically. The reuse of the original key during the transfer process further amplifies the risk of content and key leakage. Access control uses a static pre-configuration mode, where permissions are fixed after a single authentication, failing to adapt to changes in the trusted status of the terminal. The system suffers from several shortcomings. First, it lacks dynamic, minimal control over the entire lifecycle of classified calls. Unauthorized access and cross-level classified transmissions can only be traced after the fact, failing to prevent pre-emptive interception and in-process control. Second, the intelligent identification module is disconnected from the security control system, relying heavily on cloud-based large-scale model deployments, which cannot meet the requirements for localized offline operation in classified scenarios. It can only achieve basic voice recognition and call transfer execution, failing to form a closed-loop security control across the entire chain. Third, the call transfer mechanism lacks pre-authorization and classified level pre-verification, and lacks a fully tamper-proof evidence storage mechanism, making it prone to unauthorized transfers and content leaks. Furthermore, it cannot achieve traceability and non-repudiation of transfer operations. Fourth, the rigid approach of abruptly cutting off calls to address classified violations fails to balance preventing the spread of classified content with communication continuity and traceability integrity. Currently, there is no master-slave architecture secure collaborative communication solution in the industry that can simultaneously solve the above deficiencies and achieve a distributed trusted architecture and dynamic coupling closed-loop control of content, permissions, and keys. This solution cannot adapt to increasingly stringent compliance requirements and collaborative efficiency demands in classified office work. Summary of the Invention

[0003] To address the shortcomings of existing technologies, the present invention aims to provide a four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone. This method solves problems such as single-point security bottlenecks, static key risks, and rigid access control in existing technologies by using distributed trusted chain registration, dynamic access authentication, confidential gradient binding encrypted communication, dual-domain isolation, and full lifecycle key management.

[0004] To achieve the above objectives, the present invention provides the following technical solution, comprising the following steps: Step 1: Register each slave device through the distributed trusted chain and pre-configure the root key in shards to complete slave device identity registration, distributed certificate issuance and root key shard storage; Step 2: Perform chain-based bidirectional dynamic access authentication on the slave device to complete the distributed cross-authentication and dynamic permission initialization for slave device power-on access; Step 3: Establish an internal communication link between slave devices and construct dynamic encrypted communication with point-to-point confidentiality gradient binding between the master and slave devices or between slave devices. Step 4: Establish an outbound call link from the slave device to the external line, construct a dual-domain isolated dynamic encrypted communication system for outbound calls from the slave device to the external line, and intelligent identification, pre-verification, and automatic transfer of incoming calls to the external line; Step 5: After completing a communication, the host destroys the key and performs full-process audit and evidence storage to achieve a closed loop for the entire communication lifecycle.

[0005] As a further improvement of the present invention, the specific steps of registering each slave device through a distributed trusted chain and pre-setting root keys in step one to complete slave device identity registration, distributed certificate issuance and root key shard storage are as follows: Step 11: The administrator logs into the host security management system through the separation of powers and multi-factor authentication, enters the slave hardware UID, binds the user identity, department, initial confidentiality level and business scope, and establishes a unique mapping relationship of "UID-identity-initial trust level". In steps one and two, the host starts the distributed chain CA system and issues an independent SM2 digital certificate for each slave. At the same time, the Shamir secret sharing algorithm is used to split the system root key into N+1 fragments, where N is the maximum number of slave accesses. The host holds only 1 verification fragment, and each registered slave holds a unique exclusive key fragment. The system root key can only be reconstructed when ≥2 / 3 of the trusted slave fragments and the host verification fragment are combined. Step 13: Through an offline encrypted channel, the slave certificate, dedicated key fragment, host trusted public key, and initial trusted rules are written into the slave hardware security chip. Step 14: The host writes the slave registration information, certificate hash, and key shard index into an append-only, tamper-proof chained trusted evidence repository, generates a registration audit log, and completes the pre-configuration.

[0006] As a further improvement of the present invention, the specific steps for performing slave-based chain-style bidirectional dynamic access authentication in step two, and completing the distributed cross-authentication and dynamic permission initialization for slave power-on access, are as follows: Step 21: After the slave device is powered on, all communication functions are locked, only the trusted access channel is retained, and an access request is sent to the host, requesting to carry its own hardware UID, certificate signature and key fragmentation index; Step 22: The host verifies the UID filing status and certificate validity. Requests that are not filed or have mismatched certificates are directly intercepted and an alarm is triggered. After the verification is passed, at least 2 online high-trust level slave machines are randomly selected as cross-authentication nodes. Steps 2 and 3: The slave device initiating the access and the two cross-authentication nodes complete distributed two-way cross-authentication. The three parties verify the legality of the certificate and the validity of the key fragmentation to form a temporary trusted chain. If any party fails to authenticate, the access request is rejected directly and an illegal access alarm is triggered. Step 24: After cross-authentication is successful, the host and slave negotiate the temporary session key for this access. At the same time, the host generates an initial dynamic permission set for the slave that is strongly bound to the trust level, online status, and cross-authentication result, rather than a fixed pre-configured permission set. Step 25: The host synchronizes the permission set, confidentiality gradient rules, and online trusted slave list with the slave. The slave reports its online status, the host updates the trusted chain ledger, and opens the corresponding communication functions. Step 26: After the connection is completed, the system will automatically perform an iterative authentication every 30 minutes, update the slave's trusted status and dynamic permission set, and immediately lock the slave's communication permissions if authentication fails. The entire process is written to the chained trusted evidence storage library.

[0007] As a further improvement of the present invention, the specific steps for establishing an internal slave communication link in step three and constructing dynamic encrypted communication with point-to-point confidential gradient binding between the master and slave or between slaves are as follows: Step 31: The calling slave user completes identity verification, enters the called slave number to initiate a call, and requests to carry the hash value of the calling dynamic permission set, which is then encrypted and sent to the host. Step 32: The host verifies the validity of the calling party's permission set, completes the two-way matching of the confidentiality level, trust status, and business permissions of both the calling and called parties, and directly intercepts unauthorized requests and records the violation audit log. Step 33: After the permission matching is successful, the host pushes an encrypted call request to the called slave device, synchronizing the caller's identity information, permission set hash value, and trust level. After the called user completes the identity verification, he / she chooses to answer / reject the call, and the operation result is encrypted and fed back to the host. Steps 3 and 4: After the called party answers, the host initiates the initial fragment key negotiation: Based on the initial confidentiality level of both parties, the basic key for this call is generated and split into multiple fragments. Both the calling and called parties hold all the fragments of the corresponding level. Only by holding all the fragments can the complete voice data be decrypted. Step 35: After the call is established, the host starts the real-time confidentiality gradient assessment of the intelligent agent: the call content is transcribed offline by ASR, and the confidentiality gradient of the call content is assessed in real time using a semantic understanding model, including public / internal / secret / confidential / top secret, and the dynamic permission set and shard key pool are linked in sync. Step 36: When the agent detects the increase in the confidentiality gradient, it immediately triggers dynamic iteration: upgrades the temporary permission sets of the calling and called parties, generates the fragment key corresponding to the new gradient and encrypts and sends it to the slave devices of both parties, and destroys the original key fragment immediately, so that the call is not interrupted and is completely unnoticed. Step 37: When the intelligent agent recognizes that the classified content exceeds the permission level of both parties, it immediately performs targeted encryption isolation on the classified content, pushes a compliance warning, and simultaneously triggers the permission upgrade verification process, instead of directly cutting off the call; If either party hangs up the call, the host immediately terminates the forwarding link, notifies both slave devices to destroy all key fragments of this call, updates the trusted chain ledger after confirmation of destruction, and records the entire process in the chain-based evidence repository.

[0008] As a further improvement to the present invention, the specific steps for establishing the outbound call link from the slave device to the external line in step four, and constructing the dual-domain isolated dynamic encrypted communication for outbound calls from the slave device to the external line, are as follows: Step 41: The calling slave user completes identity verification and initiates an outbound call request. The host first verifies the slave's outbound call permissions, blacklist / whitelist, and confidentiality level matching. If there are no permissions, the request is directly blocked. Step 42: After the permission verification is passed, the intelligent agent pre-assesses the confidentiality gradient of the outgoing content based on the outgoing number, the called party's identity, and the business scenario, pre-generates the corresponding level of intranet fragmentation key, and sends it to the calling slave. Step 43: The host initiates a call to the outside line through the PSTN / IPSec encrypted leased line, simultaneously monitors the call status and provides real-time feedback to the calling and slave units. If the call fails, the process is terminated directly and the audit log is recorded. Step 44: After the external call is answered, the host establishes a dual-domain isolated encrypted bridge link between the internal network slave domain and the external public network domain. Intranet domain: Slave voice communication uses pre-generated fragmentation keys for hardware encryption and is only transmitted to the host. The host does not decrypt the intranet voice payload but only performs compliance verification. Bridge layer: The host uses the SM4 algorithm, a national cryptographic standard, to re-encrypt the converted voice data before sending it to the outside line. The internal and external network keys are completely isolated and have no connection. Reverse link: External voice calls are encrypted and converted by the host before being sent to the slave device, which then decrypts and plays the audio using the internal network fragmentation key; During the call, the intelligent agent assesses the confidentiality gradient in real time, dynamically updates the internal network sharding key and the bridging encryption key, and simultaneously performs the identification and control of illegal content. After the call ends, the host immediately terminates the dual-domain link, notifies the slave to destroy all key shards, destroys the internal and external network keys simultaneously, and records the entire process in a chain-based evidence repository.

[0009] As a further improvement to the present invention, the specific steps of intelligent identification, pre-verification, and automatic transfer of incoming external calls in step four are as follows: Steps four and five: When an external call comes in to the host, the host first completes the initial verification of the blacklist / whitelist and the caller's identity. Blacklisted numbers are directly blocked, while whitelisted calls are connected to the pre-set intelligent agent interaction module, completely blocking all channels directly connected to the slave device. Step 46: The intelligent agent guides the caller to explain their identity, purpose, and communication needs through TTS. It then uses offline ASR to transcribe the speech in real time, completing the extraction of core intent, assessment of confidentiality gradients, and identification of the communication entity, generating an intent hash digest that does not reveal the plaintext content. Step 47: The intelligent agent coordinates with the organizational structure library and the permission library to complete dual verification: ① Verification of the caller's identity and the access permissions of the target interface object; ② Verification of the confidentiality gradient of the incoming call content and the confidentiality level of the target slave device. If the verification fails, the call is terminated directly and an alarm log is recorded. Step 48: After the verification is successful, the intelligent agent sends a transfer instruction to the host. The host first pushes an encrypted transfer request to the target slave, carrying only the caller's identity hash, intent digest, and confidentiality gradient. Step 49: After the target slave user completes the secondary identity verification and confirms answering the call, the host initiates relay key negotiation: first negotiates the intranet fragmentation key with the target slave, and then negotiates the external temporary key with the external line. The two keys are completely isolated. Step 40: When the target slave is busy / unresponsive, the agent automatically executes the alternative rules to switch to the backup slave / on-duty slave / encrypted message, and the entire operation is hashed and stored on the blockchain. Once the call is established, the intelligent agent performs real-time identification and dynamic control of classified content. After the call ends, all keys are immediately destroyed, and the entire process is fully written into the chain-based evidence repository.

[0010] As a further improvement of the present invention, step four also includes a content-based dynamic switching step, which is as follows: Step 41: An encrypted call link has been established. The intelligent agent listens to the call content in real time according to preset rules, completes semantic understanding and trigger scenario recognition, including business matching, permission adaptation, and conference collaboration, and generates transfer decisions and target slave matching results. Step 42: The intelligent agent, in conjunction with the permission library, completes the two-way matching of permissions among the three parties: cross-verification of the confidentiality level, business permissions, and confidentiality gradient of the original two parties in the call and the target transfer slave. If the verification fails, the transfer decision is rejected and an insufficient permission prompt is pushed. Step 43: After the verification is successful, the intelligent agent pushes a transfer prompt to both parties in the call, explaining the reason for the transfer, the target object, and the result of the confidentiality gradient matching. Regular transfers require confirmation from both parties before execution; however, in confidentiality and unauthorized scenarios, no confirmation is required, and forced isolation and emergency transfer are executed directly. Step 44: After receiving the confirmation instruction, the host initiates an encrypted call to the target slave device, and simultaneously pushes the hash digest of the call content, the confidentiality gradient, and the authorization information of the participants. The target slave device answers the call after completing the identity verification. Step 45: The host initiates seamless multi-party bridging and new key negotiation: the original two parties in the call and the target transfer slave negotiate a new unified fragmentation key, which is strongly bound to the new call confidentiality gradient and multi-party permission set; before the new key negotiation is completed, the original call link remains encrypted and confidential content is temporarily isolated to achieve seamless transfer without call interruption; Step 46: After the new key negotiation is completed, the host immediately destroys the original call key, bridges the target slave to the call link, and synchronously updates the dynamic permission set of all participants. After the call is transferred, the agent continuously monitors the call content, continuously iterates the confidentiality gradient, permission set and fragmentation key, and writes the entire process into the chain-based evidence storage library.

[0011] As a further improvement of the present invention, step four also includes manual transfer permission pre-verification, full-process evidence storage and non-repudiation control steps, which are as follows: Step 47: After the encrypted call link is established, the call initiator initiates a manual transfer request on the slave device, selects the transfer mode including blind transfer and consultation transfer to the target slave device, and sends the request to the host device in encrypted form. Step 48: The host first verifies the matching of the initiator's transfer permissions and the target slave's permissions. Unauthorized requests are directly intercepted, a notification is pushed, and an audit log is recorded. Step 49: After the permission verification is passed, if you choose to switch to consultation mode: The host maintains the original call link in silence, initiates an encrypted call to the target slave, and simultaneously transfers the initiator information, the original call's security level, and the permission matching results; After the target slave device answers the call, the initiator and the target slave device establish an encrypted consultation link to confirm the intention to transfer the call. Both parties confirm that the operation generates a corresponding digital signature. After both parties confirm the transfer, the host negotiates a new unified fragmentation key, bridges the original caller and the target slave, destroys the original key, the initiator leaves the call, and the transfer is completed; If the permission verification passes and the blind transfer mode is selected: The host first completes the target slave's permission pre-verification, pre-generates a temporary session key for transfer, initiates an encrypted call to the target slave, and synchronously transfers relevant information; After the target slave device answers the call, the host immediately bridges the call link, negotiates a new fragmentation key, destroys the original key, and the initiator exits the call; When the target slave device cannot connect, the host automatically restores the original call link and pushes a call transfer failure notification; In this process, each step of the transfer process—initiation, verification, confirmation, and execution—generates a corresponding digital signature, which is then written into a chain-based trusted evidence storage library.

[0012] Another aspect of the present invention provides a refined access control and dynamic key security protection step for multi-party encrypted conferences, which are as follows: 1. The meeting initiator completes identity verification on the slave device, selects the list of participating slave devices, the initial confidentiality level of the meeting, and the control rules, initiates the meeting request, and sends it to the host device in encrypted form; 2. The host verifies the meeting initiation permission of the initiator, and at the same time completes the two-way matching of the confidentiality level and meeting level of all participating slave devices. Participants with mismatched permissions are directly removed, and insufficient permission prompts are pushed and audit logs are recorded. 3. After verification, the host creates a dedicated encrypted meeting room and generates a meeting root key + tiered shard key system: the meeting root key is split into multiple shards, and each participating slave holds a corresponding number of key shards according to its own permission level. Only the highest-level participant holds all shards and can decrypt the complete meeting content, while lower-level participants can only decrypt the meeting content of their corresponding level. IV. The host initiates an encrypted conference call to all participating slave devices, synchronizing the conference ID, confidentiality level, and access rules. For confidential conferences, participating users are required to complete a second identity verification before they can join. 5. After the participating slave device joins the conference, the host issues key fragments with corresponding permissions to complete the establishment of an end-to-end encrypted link. All participants' voice data is encrypted, forwarded and mixed through the host. The host does not decrypt the plaintext content of the conference, but only manages the link and permissions. During the meeting, when a participant joins or leaves, the host immediately updates the meeting root key and all shards, and the original key is immediately destroyed. At the same time, the agent evaluates the confidentiality gradient of the meeting content in real time, dynamically updates the meeting key shards and the participant permission set, and all operations performed by the host, such as participant management, meeting locking, and meeting termination, are hashed and stored on the blockchain. After the meeting ends, the host pushes a meeting end command to all participating slaves, notifying them to destroy all meeting key shards. After confirming the destruction is completed, the meeting room is closed, and the entire process is recorded and written to the chain-based evidence repository.

[0013] As a further improvement of the present invention, after completing a communication in step five, the host destroys the key and performs full-process audit and evidence storage to achieve a closed loop for the entire communication lifecycle. The specific steps are as follows: Step 51: After receiving the call / conference end instruction, the host immediately terminates all communication forwarding links and sends a full key destruction instruction to all slaves participating in this communication, specifying that the destruction scope includes the session key, fragment key, temporary key, and cached data of this communication; Step 52: After receiving the destruction command, each slave device completes the physical destruction of all corresponding keys and cached data within the hardware security chip, and sends a destruction confirmation receipt back to the host after the destruction is completed. Step 53: After receiving the destruction confirmation receipts from all slave devices, the host destroys the temporary key, key fragmentation index, and session cache data of this communication stored on the host side, and only retains the hashed audit log; Step 54: The host will generate a complete chain audit log for all operations throughout the entire lifecycle of this communication, including access authentication, permission verification, key negotiation, transfer operations, violation handling, and call start and end information. The log will be stored in a chain using the national cryptographic SM3 hash chain and the storage period will be no less than 180 days. Step 54: The host updates the trusted status ledger and dynamic permission set of all participating slaves, completing the closed loop of this communication process.

[0014] The beneficial effects of this invention are as follows: It solves the single-point trust bottleneck of traditional hosts through a distributed trusted chain architecture; it uses the Shamir secret sharing algorithm to achieve root key sharded storage, requiring ≥2 / 3 trusted slave shards and host verification shards to jointly reconstruct the key, effectively preventing the risk of system-wide collapse due to host intrusion. The dynamic access authentication mechanism, through chained cross-authentication and 30-minute iterative authentication, achieves real-time updates of slave trust status, solving the problem of unauthorized access under static permission control. Dynamic encrypted communication with classified information gradient binding, based on offline ASR and semantic understanding, achieves real-time classification of call content. Through dynamic key iteration and targeted encryption isolation, it ensures the security of classified content while avoiding rigid call termination. The dual-domain isolation mechanism ensures complete independence of internal and external network keys, combined with full lifecycle key destruction and chained evidence storage, solving the risks of key reuse and content leakage. Subsequent improvements further enhance system collaboration efficiency and security control granularity, achieving an organic unity of confidentiality protection and collaborative communication. Detailed Implementation

[0015] The present invention will be further described in detail below with reference to the given embodiments.

[0016] The four-dimensional dynamic coupling communication method for the master-slave architecture secure collaborative telephone in this embodiment includes the following steps: Step 1: Register each slave device through the distributed trusted chain and pre-configure the root key in shards to complete slave device identity registration, distributed certificate issuance and root key shard storage; Step 2: Perform chain-based bidirectional dynamic access authentication on the slave device to complete the distributed cross-authentication and dynamic permission initialization for slave device power-on access; Step 3: Establish an internal communication link between slave devices and construct dynamic encrypted communication with point-to-point confidentiality gradient binding between the master and slave devices or between slave devices. Step 4: Establish an outbound call link from the slave device to the external line, construct a dual-domain isolated dynamic encrypted communication system for outbound calls from the slave device to the external line, and intelligent identification, pre-verification, and automatic transfer of incoming calls to the external line; Step 5: After completing a communication, the host destroys the key and performs full-process audit and evidence storage to achieve a closed loop for the entire communication lifecycle.

[0017] This method extends the traditional single-machine root of trust to a multi-node collaborative trust system through a distributed trusted chain. The root key sharding storage mechanism ensures that a compromised single node cannot obtain the complete key, thus resolving the single point of failure risk of the host in the background technology. Dynamic access authentication ensures dynamic matching between slave device access status and permissions through real-time cross-validation and permission iteration, avoiding the permission fixation problem caused by static configuration. Dynamic encryption with classified information gradients and dual-domain isolation technology achieve real-time adaptation of content sensitivity and key strength. Combined with a full-process key destruction mechanism, this fundamentally solves the security risks of static keys and permission control.

[0018] Furthermore, the specific steps in step one—registering each slave device through a distributed trusted chain and pre-setting root keys in shards—to complete slave device identity registration, distributed certificate issuance, and sharded root key storage are as follows: Step 11: The administrator logs into the host security management system through the separation of powers and multi-factor authentication, enters the slave hardware UID, binds the user identity, department, initial confidentiality level and business scope, and establishes a unique mapping relationship of "UID-identity-initial trust level". In steps one and two, the host starts the distributed chain CA system and issues an independent SM2 digital certificate for each slave. At the same time, the Shamir secret sharing algorithm is used to split the system root key into N+1 fragments, where N is the maximum number of slave accesses. The host holds only 1 verification fragment, and each registered slave holds a unique exclusive key fragment. The system root key can only be reconstructed when ≥2 / 3 of the trusted slave fragments and the host verification fragment are combined. Step 13: Through an offline encrypted channel, the slave certificate, dedicated key fragment, host trusted public key, and initial trusted rules are written into the slave hardware security chip. Step 14: The host writes the slave registration information, certificate hash, and key shard index into an append-only, tamper-proof chained trusted evidence repository, generates a registration audit log, and completes the pre-configuration.

[0019] This step ensures the uniqueness and immutability of the slave device's identity through a three-tiered authentication and hardware binding mechanism. The key sharding strategy of the Shamir algorithm further disperses the key management risks, solving the security risks of centralized key storage in the background technology. At the same time, the chain-like evidence repository provides an immutable chain of evidence for subsequent auditing and tracing.

[0020] Furthermore, in step two, a chain-based bidirectional dynamic access authentication is performed on the slave device. The specific steps for completing the distributed cross-authentication and dynamic permission initialization for slave device power-on access are as follows: Step 21: After the slave device is powered on, all communication functions are locked, only the trusted access channel is retained, and an access request is sent to the host, requesting to carry its own hardware UID, certificate signature and key fragmentation index; Step 22: The host verifies the UID filing status and certificate validity. Requests that are not filed or have mismatched certificates are directly intercepted and an alarm is triggered. After the verification is passed, at least 2 online high-trust level slave machines are randomly selected as cross-authentication nodes. Steps 2 and 3: The slave device initiating the access and the two cross-authentication nodes complete distributed two-way cross-authentication. The three parties verify the legality of the certificate and the validity of the key fragmentation to form a temporary trusted chain. If any party fails to authenticate, the access request is rejected directly and an illegal access alarm is triggered. Step 24: After cross-authentication is successful, the host and slave negotiate the temporary session key for this access. At the same time, the host generates an initial dynamic permission set for the slave that is strongly bound to the trust level, online status, and cross-authentication result, rather than a fixed pre-configured permission set. Step 25: The host synchronizes the permission set, confidentiality gradient rules, and online trusted slave list with the slave. The slave reports its online status, the host updates the trusted chain ledger, and opens the corresponding communication functions. Step 26: After the connection is completed, the system will automatically perform an iterative authentication every 30 minutes, update the slave's trusted status and dynamic permission set, and immediately lock the slave's communication permissions if authentication fails. The entire process is written to the chained trusted evidence storage library.

[0021] This step achieves multi-node mutual trust verification for slave access through distributed cross-authentication and dynamic permission generation. The 30-minute iterative authentication mechanism ensures the continuous updating of the slave's trusted status, solving the problem of one-time authentication and lifetime validity of permissions in the background technology. At the same time, real-time alarm and evidence storage functions enhance the traceability of abnormal access.

[0022] Furthermore, the specific steps for establishing internal inter-slave communication links in step three, and constructing point-to-point dynamic encrypted communication with confidentiality gradient binding between the master and slave devices or between slave devices, are as follows: Step 31: The calling slave user completes identity verification, enters the called slave number to initiate a call, and requests to carry the hash value of the calling dynamic permission set, which is then encrypted and sent to the host. Step 32: The host verifies the validity of the calling party's permission set, completes the two-way matching of the confidentiality level, trust status, and business permissions of both the calling and called parties, and directly intercepts unauthorized requests and records the violation audit log. Step 33: After the permission matching is successful, the host pushes an encrypted call request to the called slave device, synchronizing the caller's identity information, permission set hash value, and trust level. After the called user completes the identity verification, he / she chooses to answer / reject the call, and the operation result is encrypted and fed back to the host. Steps 3 and 4: After the called party answers, the host initiates the initial fragment key negotiation: Based on the initial confidentiality level of both parties, the basic key for this call is generated and split into multiple fragments. Both the calling and called parties hold all the fragments of the corresponding level. Only by holding all the fragments can the complete voice data be decrypted. Step 35: After the call is established, the host starts the real-time confidentiality gradient assessment of the intelligent agent: the call content is transcribed offline by ASR, and the confidentiality gradient of the call content is assessed in real time using a semantic understanding model, including public / internal / secret / confidential / top secret, and the dynamic permission set and shard key pool are linked in sync. Step 36: When the agent detects the increase in the confidentiality gradient, it immediately triggers dynamic iteration: upgrades the temporary permission sets of the calling and called parties, generates the fragment key corresponding to the new gradient and encrypts and sends it to the slave devices of both parties, and destroys the original key fragment immediately, so that the call is not interrupted and is completely unnoticed. Step 37: When the intelligent agent recognizes that the classified content exceeds the permission level of both parties, it immediately performs targeted encryption isolation on the classified content, pushes a compliance warning, and simultaneously triggers the permission upgrade verification process, instead of directly cutting off the call; If either party hangs up the call, the host immediately terminates the forwarding link, notifies both slave devices to destroy all key fragments of this call, updates the trusted chain ledger after confirmation of destruction, and records the entire process in the chain-based evidence repository.

[0023] This step achieves real-time adaptation of call content and key strength through two-way permission matching and dynamic key iteration. Offline ASR and semantic understanding technologies avoid cloud dependence and solve the problem of disconnect between intelligent identification and security control in the background technology. The targeted encryption isolation mechanism maintains communication continuity while ensuring confidentiality security and overcomes the drawbacks of traditional one-size-fits-all call termination.

[0024] Furthermore, in step four, the specific steps for establishing the outbound call link from the slave device to the external line and constructing the dual-domain isolated dynamic encrypted communication for outbound calls from the slave device to the external line are as follows: Step 41: The calling slave user completes identity verification and initiates an outbound call request. The host first verifies the slave's outbound call permissions, blacklist / whitelist, and confidentiality level matching. If there are no permissions, the request is directly blocked. Step 42: After the permission verification is passed, the intelligent agent pre-assesses the confidentiality gradient of the outgoing content based on the outgoing number, the called party's identity, and the business scenario, pre-generates the corresponding level of intranet fragmentation key, and sends it to the calling slave. Step 43: The host initiates a call to the outside line through the PSTN / IPSec encrypted leased line, simultaneously monitors the call status and provides real-time feedback to the calling and slave units. If the call fails, the process is terminated directly and the audit log is recorded. Step 44: After the external call is answered, the host establishes a dual-domain isolated encrypted bridge link between the internal network slave domain and the external public network domain. Intranet domain: Slave voice communication uses pre-generated fragmentation keys for hardware encryption and is only transmitted to the host. The host does not decrypt the intranet voice payload but only performs compliance verification. Bridge layer: The host uses the SM4 algorithm, a national cryptographic standard, to re-encrypt the converted voice data before sending it to the outside line. The internal and external network keys are completely isolated and have no connection. Reverse link: External voice calls are encrypted and converted by the host before being sent to the slave device, which then decrypts and plays the audio using the internal network fragmentation key; During the call, the intelligent agent assesses the confidentiality gradient in real time, dynamically updates the internal network sharding key and the bridging encryption key, and simultaneously performs the identification and control of illegal content. After the call ends, the host immediately terminates the dual-domain link, notifies the slave to destroy all key shards, destroys the internal and external network keys simultaneously, and records the entire process in a chain-based evidence repository.

[0025] This step addresses the risk of external network communication key leakage in the background technology through dual-domain isolation and complete key isolation mechanisms. Pre-assessment and dynamic key update technologies achieve full lifecycle security protection for outgoing content, while the host-not-decryption design ensures end-to-end security of internal network voice data.

[0026] Furthermore, the specific steps for intelligent identification, pre-verification, and automatic transfer of incoming calls in step four are as follows: Steps four and five: When an external call comes in to the host, the host first completes the initial verification of the blacklist / whitelist and the caller's identity. Blacklisted numbers are directly blocked, while whitelisted calls are connected to the pre-set intelligent agent interaction module, completely blocking all channels directly connected to the slave device. Step 46: The intelligent agent guides the caller to explain their identity, purpose, and communication needs through TTS. It then uses offline ASR to transcribe the speech in real time, completing the extraction of core intent, assessment of confidentiality gradients, and identification of the communication entity, generating an intent hash digest that does not reveal the plaintext content. Step 47: The intelligent agent coordinates with the organizational structure library and the permission library to complete dual verification: ① Verification of the caller's identity and the access permissions of the target interface object; ② Verification of the confidentiality gradient of the incoming call content and the confidentiality level of the target slave device. If the verification fails, the call is terminated directly and an alarm log is recorded. Step 48: After the verification is successful, the intelligent agent sends a transfer instruction to the host. The host first pushes an encrypted transfer request to the target slave, carrying only the caller's identity hash, intent digest, and confidentiality gradient. Step 49: After the target slave user completes the secondary identity verification and confirms answering the call, the host initiates relay key negotiation: first negotiates the intranet fragmentation key with the target slave, and then negotiates the external temporary key with the external line. The two keys are completely isolated. Step 40: When the target slave is busy / unresponsive, the agent automatically executes the alternative rules to switch to the backup slave / on-duty slave / encrypted message, and the entire operation is hashed and stored on the blockchain. Once the call is established, the intelligent agent performs real-time identification and dynamic control of classified content. After the call ends, all keys are immediately destroyed, and the entire process is fully written into the chain-based evidence repository.

[0027] This step addresses the risk of unauthorized transfers in the background technology through pre-authorization verification and intent hashing. Relay-style key negotiation ensures the isolation of internal and external network keys. The offline intelligent interaction module meets the localized operation requirements of classified scenarios. Full-process evidence storage ensures the non-repudiation of the transfer operation.

[0028] Furthermore, step four also includes a content-based dynamic switching step, which is detailed below: Step 41: An encrypted call link has been established. The intelligent agent listens to the call content in real time according to preset rules, completes semantic understanding and trigger scenario recognition, including business matching, permission adaptation, and conference collaboration, and generates transfer decisions and target slave matching results. Step 42: The intelligent agent, in conjunction with the permission library, completes the two-way matching of permissions among the three parties: cross-verification of the confidentiality level, business permissions, and confidentiality gradient of the original two parties in the call and the target transfer slave. If the verification fails, the transfer decision is rejected and an insufficient permission prompt is pushed. Step 43: After the verification is successful, the intelligent agent pushes a transfer prompt to both parties in the call, explaining the reason for the transfer, the target object, and the result of the confidentiality gradient matching. Regular transfers require confirmation from both parties before execution; however, in confidentiality and unauthorized scenarios, no confirmation is required, and forced isolation and emergency transfer are executed directly. Step 44: After receiving the confirmation instruction, the host initiates an encrypted call to the target slave device, and simultaneously pushes the hash digest of the call content, the confidentiality gradient, and the authorization information of the participants. The target slave device answers the call after completing the identity verification. Step 45: The host initiates seamless multi-party bridging and new key negotiation: the original two parties in the call and the target transfer slave negotiate a new unified fragmentation key, which is strongly bound to the new call confidentiality gradient and multi-party permission set; before the new key negotiation is completed, the original call link remains encrypted and confidential content is temporarily isolated to achieve seamless transfer without call interruption; Step 46: After the new key negotiation is completed, the host immediately destroys the original call key, bridges the target slave to the call link, and synchronously updates the dynamic permission set of all participants. After the call is transferred, the agent continuously monitors the call content, continuously iterates the confidentiality gradient, permission set and fragmentation key, and writes the entire process into the chain-based evidence storage library.

[0029] This step addresses the lack of security control in traditional transfer mechanisms through content-driven dynamic transfer and third-party permission verification. Seamless bridging technology ensures communication continuity while enabling real-time key updates, further strengthening the security protection of classified content during the transfer process.

[0030] Furthermore, step four also includes manual transfer of permissions pre-verification, full-process evidence storage, and non-repudiation control steps, which are detailed below: Step 47: After the encrypted call link is established, the call initiator initiates a manual transfer request on the slave device, selects the transfer mode including blind transfer and consultation transfer to the target slave device, and sends the request to the host device in encrypted form. Step 48: The host first verifies the matching of the initiator's transfer permissions and the target slave's permissions. Unauthorized requests are directly intercepted, a notification is pushed, and an audit log is recorded. Step 49: After the permission verification is passed, if you choose to switch to consultation mode: The host maintains the original call link in silence, initiates an encrypted call to the target slave, and simultaneously transfers the initiator information, the original call's security level, and the permission matching results; After the target slave device answers the call, the initiator and the target slave device establish an encrypted consultation link to confirm the intention to transfer the call. Both parties confirm that the operation generates a corresponding digital signature. After both parties confirm the transfer, the host negotiates a new unified fragmentation key, bridges the original caller and the target slave, destroys the original key, the initiator leaves the call, and the transfer is completed; If the permission verification passes and the blind transfer mode is selected: The host first completes the target slave's permission pre-verification, pre-generates a temporary session key for transfer, initiates an encrypted call to the target slave, and synchronously transfers relevant information; After the target slave device answers the call, the host immediately bridges the call link, negotiates a new fragmentation key, destroys the original key, and the initiator exits the call; When the target slave device cannot connect, the host automatically restores the original call link and pushes a call transfer failure notification; In this process, each step of the transfer process—initiation, verification, confirmation, and execution—generates a corresponding digital signature, which is then written into a chain-based trusted evidence storage library.

[0031] This step addresses the risks of unauthorized access and operational repudiation during manual transfers through sophisticated permission verification and digital signature notarization. The encrypted negotiation mechanism in the consultation-to-transfer mode ensures the security of the transfer intention confirmation process, while the pre-verification and key update mechanism in the blind transfer mode improves efficiency while guaranteeing security.

[0032] Furthermore, another aspect of the present invention provides refined access control and dynamic key security protection steps for multi-party encrypted conferences, which are as follows: 1. The meeting initiator completes identity verification on the slave device, selects the list of participating slave devices, the initial confidentiality level of the meeting, and the control rules, initiates the meeting request, and sends it to the host device in encrypted form; 2. The host verifies the meeting initiation permission of the initiator, and at the same time completes the two-way matching of the confidentiality level and meeting level of all participating slave devices. Participants with mismatched permissions are directly removed, and insufficient permission prompts are pushed and audit logs are recorded. 3. After verification, the host creates a dedicated encrypted meeting room and generates a meeting root key + tiered shard key system: the meeting root key is split into multiple shards, and each participating slave holds a corresponding number of key shards according to its own permission level. Only the highest-level participant holds all shards and can decrypt the complete meeting content, while lower-level participants can only decrypt the meeting content of their corresponding level. IV. The host initiates an encrypted conference call to all participating slave devices, synchronizing the conference ID, confidentiality level, and access rules. For confidential conferences, participating users are required to complete a second identity verification before they can join. 5. After the participating slave device joins the conference, the host issues key fragments with corresponding permissions to complete the establishment of an end-to-end encrypted link. All participants' voice data is encrypted, forwarded and mixed through the host. The host does not decrypt the plaintext content of the conference, but only manages the link and permissions. During the meeting, when a participant joins or leaves, the host immediately updates the meeting root key and all shards, and the original key is immediately destroyed. At the same time, the agent evaluates the confidentiality gradient of the meeting content in real time, dynamically updates the meeting key shards and the participant permission set, and all operations performed by the host, such as participant management, meeting locking, and meeting termination, are hashed and stored on the blockchain. After the meeting ends, the host pushes a meeting end command to all participating slaves, notifying them to destroy all meeting key shards. After confirming the destruction is completed, the meeting room is closed, and the entire process is recorded and written to the chain-based evidence repository.

[0033] This step achieves fine-grained access control of meeting content through a permission-based key sharding mechanism, solving the problem of coarse permission management in traditional meeting systems. The full key update mechanism when participants change effectively prevents the risk of key leakage, and real-time confidentiality gradient assessment further ensures the dynamic security of meeting content.

[0034] Furthermore, after completing a communication in step five, the host destroys the key and performs full-process audit and evidence storage, achieving a closed loop for the entire communication lifecycle. The specific steps are as follows: Step 51: After receiving the call / conference end instruction, the host immediately terminates all communication forwarding links and sends a full key destruction instruction to all slaves participating in this communication, specifying that the destruction scope includes the session key, fragment key, temporary key, and cached data of this communication; Step 52: After receiving the destruction command, each slave device completes the physical destruction of all corresponding keys and cached data within the hardware security chip, and sends a destruction confirmation receipt back to the host after the destruction is completed. Step 53: After receiving the destruction confirmation receipts from all slave devices, the host destroys the temporary key, key fragmentation index, and session cache data of this communication stored on the host side, and only retains the hashed audit log; Step 54: The host will generate a complete chain audit log for all operations throughout the entire lifecycle of this communication, including access authentication, permission verification, key negotiation, transfer operations, violation handling, and call start and end information. The log will be stored in a chain using the national cryptographic SM3 hash chain and the storage period will be no less than 180 days. Step 54: The host updates the trusted status ledger and dynamic permission set of all participating slaves, completing the closed loop of this communication process.

[0035] This step achieves secure closed-loop management of the entire communication lifecycle through hardware-level key destruction and chain-based audit evidence storage, solving the problems of key residue and insufficient audit traceability in the background technology. The 180-day hash chain storage meets the compliance retention requirements for classified scenarios.

[0036] In summary, the four-dimensional dynamic coupling communication method for master-slave architecture confidential collaborative telephones provided by this invention solves the problems of single-point security bottlenecks, static key risks, rigid access control, and disconnect between intelligent identification and security control in existing technologies through a collaborative mechanism of distributed trusted chain registration, chain-based dynamic access authentication, confidential gradient binding encrypted communication, dual-domain isolation, and full lifecycle key management. It achieves the organic unity of high-level confidentiality protection and efficient collaborative communication, meeting the compliance requirements and efficiency needs of confidential office scenarios.

[0037] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone, characterized in that: Includes the following steps: Step 1: Register each slave device through the distributed trusted chain and pre-configure the root key in shards to complete slave device identity registration, distributed certificate issuance and root key shard storage; Step 2: Perform chain-based bidirectional dynamic access authentication on the slave device to complete the distributed cross-authentication and dynamic permission initialization for slave device power-on access; Step 3: Establish an internal communication link between slave devices and construct dynamic encrypted communication with point-to-point confidentiality gradient binding between the master and slave devices or between slave devices. Step 4: Establish an outbound call link from the slave device to the external line, construct a dual-domain isolated dynamic encrypted communication system for outbound calls from the slave device to the external line, and intelligent identification, pre-verification, and automatic transfer of incoming calls to the external line; Step 5: After completing a communication, the host destroys the key and performs full-process audit and evidence storage to achieve a closed loop for the entire communication lifecycle.

2. The four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone according to claim 1, characterized in that: The specific steps in step one, which involve registering each slave device through a distributed trusted chain and pre-setting root keys in shards to complete slave device identity registration, distributed certificate issuance, and sharded root key storage, are as follows: Step 11: The administrator logs into the host security management system through the separation of powers and multi-factor authentication, enters the slave hardware UID, binds the user identity, department, initial confidentiality level and business scope, and establishes a unique mapping relationship of "UID-identity-initial trust level". In steps one and two, the host starts the distributed chain CA system and issues an independent SM2 digital certificate for each slave. At the same time, the Shamir secret sharing algorithm is used to split the system root key into N+1 fragments, where N is the maximum number of slave accesses. The host holds only 1 verification fragment, and each registered slave holds a unique exclusive key fragment. The system root key can only be reconstructed when ≥2 / 3 of the trusted slave fragments and the host verification fragment are combined. Step 13: Through an offline encrypted channel, the slave certificate, dedicated key fragment, host trusted public key, and initial trusted rules are written into the slave hardware security chip. Step 14: The host writes the slave registration information, certificate hash, and key shard index into an append-only, tamper-proof chained trusted evidence repository, generates a registration audit log, and completes the pre-configuration.

3. The four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone according to claim 1 or 2, characterized in that: In step two, the slave machine performs chain-based bidirectional dynamic access authentication. The specific steps for completing the distributed cross-authentication and dynamic permission initialization for slave machine power-on access are as follows: Step 21: After the slave device is powered on, all communication functions are locked, only the trusted access channel is retained, and an access request is sent to the host, requesting to carry its own hardware UID, certificate signature and key fragmentation index; Step 22: The host verifies the UID filing status and certificate validity. Requests that are not filed or have mismatched certificates are directly intercepted and an alarm is triggered. After verification, at least two online, highly trusted slave machines are randomly selected as cross-authentication nodes. Steps 2 and 3: The slave device initiating the access and the two cross-authentication nodes complete distributed two-way cross-authentication. The three parties verify the legality of the certificate and the validity of the key fragmentation to form a temporary trusted chain. If any party fails to authenticate, the access request is rejected directly and an illegal access alarm is triggered. Step 24: After cross-authentication is successful, the host and slave negotiate the temporary session key for this access. At the same time, the host generates an initial dynamic permission set for the slave that is strongly bound to the trust level, online status, and cross-authentication result, rather than a fixed pre-configured permission set. Step 25: The host synchronizes the permission set, confidentiality gradient rules, and online trusted slave list with the slave. The slave reports its online status, the host updates the trusted chain ledger, and opens the corresponding communication functions. Step 26: After the connection is completed, the system will automatically perform an iterative authentication every 30 minutes, update the slave's trusted status and dynamic permission set, and immediately lock the slave's communication permissions if authentication fails. The entire process is written to the chained trusted evidence storage library.

4. The four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone according to claim 1 or 2, characterized in that: The specific steps for establishing an internal inter-slave communication link in step three, and constructing point-to-point dynamic encrypted communication with confidentiality gradient binding between the master and slave or between slaves, are as follows: Step 31: The calling slave user completes identity verification, enters the called slave number to initiate a call, and requests to carry the hash value of the calling dynamic permission set, which is then encrypted and sent to the host. Step 32: The host verifies the validity of the calling party's permission set, completes the two-way matching of the confidentiality level, trust status, and business permissions of both the calling and called parties, and directly intercepts unauthorized requests and records the violation audit log. Step 33: After the permission matching is successful, the host pushes an encrypted call request to the called slave device, synchronizing the caller's identity information, permission set hash value, and trust level. After the called user completes the identity verification, he / she chooses to answer / reject the call, and the operation result is encrypted and fed back to the host. Steps 3 and 4: After the called party answers, the host initiates the initial fragment key negotiation: Based on the initial confidentiality level of both parties, the basic key for this call is generated and split into multiple fragments. Both the calling and called parties hold all the fragments of the corresponding level. Only by holding all the fragments can the complete voice data be decrypted. Step 35: After the call is established, the host starts the real-time confidentiality gradient assessment of the intelligent agent: the call content is transcribed offline by ASR, and the confidentiality gradient of the call content is assessed in real time using a semantic understanding model, including public / internal / secret / confidential / top secret, and the dynamic permission set and shard key pool are linked in sync. Step 36: When the agent detects the increase in the confidentiality gradient, it immediately triggers dynamic iteration: upgrades the temporary permission sets of the calling and called parties, generates the fragment key corresponding to the new gradient and encrypts and sends it to the slave devices of both parties, and destroys the original key fragment immediately, so that the call is not interrupted and is completely unnoticed. Step 37: When the intelligent agent recognizes that the classified content exceeds the permission level of both parties, it immediately performs targeted encryption isolation on the classified content, pushes a compliance warning, and simultaneously triggers the permission upgrade verification process, instead of directly cutting off the call; If either party hangs up the call, the host immediately terminates the forwarding link, notifies both slave devices to destroy all key fragments of this call, updates the trusted chain ledger after confirmation of destruction, and records the entire process in the chain-based evidence repository.

5. The four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone according to claim 1 or 2, characterized in that: The specific steps for establishing the outbound call link from the slave device to the external line in step four, and constructing the dual-domain isolated dynamic encrypted communication for outbound calls from the slave device to the external line, are as follows: Step 41: The calling slave user completes identity verification and initiates an outbound call request. The host first verifies the slave's outbound call permissions, blacklist / whitelist, and confidentiality level matching. If there are no permissions, the request is directly blocked. Step 42: After the permission verification is passed, the intelligent agent pre-assesses the confidentiality gradient of the outgoing content based on the outgoing number, the called party's identity, and the business scenario, pre-generates the corresponding level of intranet fragmentation key, and sends it to the calling slave. Step 43: The host initiates a call to the outside line through the PSTN / IPSec encrypted leased line, simultaneously monitors the call status and provides real-time feedback to the calling and slave units. If the call fails, the process is terminated directly and the audit log is recorded. Step 44: After the external call is answered, the host establishes a dual-domain isolated encrypted bridge link between the internal network slave domain and the external public network domain. Intranet domain: Slave voice communication uses pre-generated fragmentation keys for hardware encryption and is only transmitted to the host. The host does not decrypt the intranet voice payload but only performs compliance verification. Bridge layer: The host uses the SM4 algorithm, a national cryptographic standard, to re-encrypt the converted voice data before sending it to the outside line. The internal and external network keys are completely isolated and have no connection. Reverse link: External voice calls are encrypted and converted by the host before being sent to the slave device, which then decrypts and plays the audio using the internal network fragmentation key; During the call, the intelligent agent assesses the confidentiality gradient in real time, dynamically updates the internal network sharding key and the bridging encryption key, and simultaneously performs the identification and control of illegal content. After the call ends, the host immediately terminates the dual-domain link, notifies the slave to destroy all key shards, destroys the internal and external network keys simultaneously, and records the entire process in a chain-based evidence repository.

6. The four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone according to claim 5, characterized in that: The specific steps for intelligent identification, pre-verification, and automatic transfer of incoming external calls in step four are as follows: Steps four and five: When an external call comes in to the host, the host first completes the initial verification of the blacklist / whitelist and the caller's identity. Blacklisted numbers are directly blocked, while whitelisted calls are connected to the pre-set intelligent agent interaction module, completely blocking all channels directly connected to the slave device. Step 46: The intelligent agent guides the caller to explain their identity, purpose, and communication needs through TTS. It then uses offline ASR to transcribe the speech in real time, completing the extraction of core intent, assessment of confidentiality gradients, and identification of the communication entity, generating an intent hash digest that does not reveal the plaintext content. Step 47: The intelligent agent coordinates with the organizational structure library and the permission library to complete dual verification: ① Verification of the caller's identity and the access permissions of the target interface object; ② Verification of the confidentiality gradient of the incoming call content and the confidentiality level of the target slave device. If the verification fails, the call is terminated directly and an alarm log is recorded. Step 48: After the verification is successful, the intelligent agent sends a transfer instruction to the host. The host first pushes an encrypted transfer request to the target slave, carrying only the caller's identity hash, intent digest, and confidentiality gradient. Step 49: After the target slave user completes the secondary identity verification and confirms answering the call, the host initiates relay key negotiation: first negotiates the intranet fragmentation key with the target slave, and then negotiates the external temporary key with the external line. The two keys are completely isolated. Step 40: When the target slave is busy / unresponsive, the agent automatically executes the alternative rules to switch to the backup slave / on-duty slave / encrypted message, and the entire operation is hashed and stored on the blockchain. Once the call is established, the intelligent agent performs real-time identification and dynamic control of classified content. After the call ends, all keys are immediately destroyed, and the entire process is fully written into the chain-based evidence repository.

7. The four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone according to claim 6, characterized in that: Step four also includes a content-based dynamic switching step, which is as follows: Step 41: An encrypted call link has been established. The intelligent agent listens to the call content in real time according to preset rules, completes semantic understanding and trigger scenario recognition, including business matching, permission adaptation, and conference collaboration, and generates transfer decisions and target slave matching results. Step 42: The intelligent agent, in conjunction with the permission library, completes the two-way matching of permissions among the three parties: cross-verification of the confidentiality level, business permissions, and confidentiality gradient of the original two parties in the call and the target transfer slave. If the verification fails, the transfer decision is rejected and an insufficient permission prompt is pushed. Step 43: After the verification is successful, the intelligent agent pushes a transfer prompt to both parties in the call, explaining the reason for the transfer, the target object, and the result of the confidentiality gradient matching. Regular transfers require confirmation from both parties before execution; however, in confidentiality and unauthorized scenarios, no confirmation is required, and forced isolation and emergency transfer are executed directly. Step 44: After receiving the confirmation instruction, the host initiates an encrypted call to the target slave device, and simultaneously pushes the hash digest of the call content, the confidentiality gradient, and the authorization information of the participants. The target slave device answers the call after completing the identity verification. Step 45: The host initiates seamless multi-party bridging and new key negotiation: the original two parties in the call and the target transfer slave negotiate a brand-new unified fragmentation key, and the key is strongly bound to the new call confidentiality gradient and multi-party permission set; Before the new key negotiation is completed, the original call link remains encrypted and classified content is temporarily isolated to achieve seamless transfer without call interruption. Step 46: After the new key negotiation is completed, the host immediately destroys the original call key, bridges the target slave to the call link, and synchronously updates the dynamic permission set of all participants. After the call is transferred, the agent continuously monitors the call content, continuously iterates the confidentiality gradient, permission set and fragmentation key, and writes the entire process into the chain-based evidence storage library.

8. The four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone according to claim 7, characterized in that: Step four also includes manual transfer of permissions pre-verification, full-process evidence storage, and non-repudiation control steps, which are detailed below: Step 47: After the encrypted call link is established, the call initiator initiates a manual transfer request on the slave device, selects the transfer mode including blind transfer and consultation transfer to the target slave device, and sends the request to the host device in encrypted form. Step 48: The host first verifies the matching of the initiator's transfer permissions and the target slave's permissions. Unauthorized requests are directly intercepted, a notification is pushed, and an audit log is recorded. Step 49: After the permission verification is passed, if you choose to switch to consultation mode: The host maintains the original call link in silence, initiates an encrypted call to the target slave, and simultaneously transfers the initiator information, the original call's security level, and the permission matching results; After the target slave device answers the call, the initiator and the target slave device establish an encrypted consultation link to confirm the intention to transfer the call. Both parties confirm that the operation generates a corresponding digital signature. After both parties confirm the transfer, the host negotiates a new unified fragmentation key, bridges the original caller and the target slave, destroys the original key, the initiator leaves the call, and the transfer is completed; If the permission verification passes and the blind transfer mode is selected: The host first completes the target slave's permission pre-verification, pre-generates a temporary session key for transfer, initiates an encrypted call to the target slave, and synchronously transfers relevant information; After the target slave device answers the call, the host immediately bridges the call link, negotiates a new fragmentation key, destroys the original key, and the initiator exits the call; When the target slave device cannot connect, the host automatically restores the original call link and pushes a call transfer failure notification; In this process, each step of the transfer process—initiation, verification, confirmation, and execution—generates a corresponding digital signature, which is then written into a chain-based trusted evidence storage library.

9. The four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone according to claim 8, characterized in that: Step four also includes fine-grained access control and dynamic key security protection for multi-party encrypted conferences, as detailed below:

1. The meeting initiator completes identity verification on the slave device, selects the list of participating slave devices, the initial confidentiality level of the meeting, and the control rules, initiates the meeting request, and sends it to the host device in encrypted form; 2. The host verifies the meeting initiation permission of the initiator, and at the same time completes the two-way matching of the confidentiality level and meeting level of all participating slave devices. Participants with mismatched permissions are directly removed, and insufficient permission prompts are pushed and audit logs are recorded.

3. After verification, the host creates a dedicated encrypted meeting room and generates a meeting root key + tiered shard key system: the meeting root key is split into multiple shards, and each participating slave holds a corresponding number of key shards according to its own permission level. Only the highest-level participant holds all shards and can decrypt the complete meeting content, while lower-level participants can only decrypt the meeting content of their corresponding level. IV. The host initiates an encrypted conference call to all participating slave devices, synchronizing the conference ID, confidentiality level, and access rules. For confidential conferences, participating users are required to complete a second identity verification before they can join.

5. After the participating slave device joins the conference, the host issues key fragments with corresponding permissions to complete the establishment of an end-to-end encrypted link. All participants' voice data is encrypted, forwarded and mixed through the host. The host does not decrypt the plaintext content of the conference, but only manages the link and permissions. During the meeting, when a participant joins or leaves, the host immediately updates the meeting root key and all shards, and the original key is immediately destroyed. At the same time, the agent evaluates the confidentiality gradient of the meeting content in real time, dynamically updates the meeting key shards and the participant permission set, and all operations performed by the host, such as participant management, meeting locking, and meeting termination, are hashed and stored on the blockchain. After the meeting ends, the host pushes a meeting end command to all participating slaves, notifying them to destroy all meeting key shards. After confirming the destruction is completed, the meeting room is closed, and the entire process is recorded and written to the chain-based evidence repository.

10. The four-dimensional dynamic coupling communication method for a master-slave architecture secure collaborative telephone according to claim 1 or 2, characterized in that: After completing a communication in step five, the host destroys the key and performs full-process audit and evidence storage to achieve a closed loop for the entire communication lifecycle. The specific steps are as follows: Step 51: After receiving the call / conference end instruction, the host immediately terminates all communication forwarding links and sends a full key destruction instruction to all slaves participating in this communication, specifying that the destruction scope includes the session key, fragment key, temporary key, and cached data of this communication; Step 52: After receiving the destruction command, each slave device completes the physical destruction of all corresponding keys and cached data within the hardware security chip, and sends a destruction confirmation receipt back to the host after the destruction is completed. Step 53: After receiving the destruction confirmation receipts from all slave devices, the host destroys the temporary key, key fragmentation index, and session cache data of this communication stored on the host side, and only retains the hashed audit log; Step 54: The host will generate a complete chain audit log for all operations throughout the entire lifecycle of this communication, including access authentication, permission verification, key negotiation, transfer operations, violation handling, and call start and end information. The log will be stored in a chain using the national cryptographic SM3 hash chain and the storage period will be no less than 180 days. Step 54: The host updates the trusted status ledger and dynamic permission set of all participating slaves, completing the closed loop of this communication process.