Key distribution and communication adaptation methods and related equipment for walkie-talkies

Abstract

This invention relates to a key distribution and communication adaptation method and related equipment for walkie-talkies, comprising the following steps: extracting a terminal identity feature code from the walkie-talkie terminal device identification information, and generating a key generation factor by XORing it with a preset random number seed; using this factor to distribute a pre-stored stub key to obtain a session key ciphertext and sending it to the target terminal; the target terminal decrypting the ciphertext using a locally stored distributed key to obtain the session key plaintext, and verifying its legitimacy through a message authentication code; if the verification is successful and there is a voice communication request to be initiated, then encrypting each frame of voice data frame by frame based on the session key plaintext to generate encrypted voice data frames, and encapsulating them into communication data packets carrying a key version identifier for transmission, thus solving the technical problem of achieving end-to-end encrypted voice transmission in half-duplex mode and ensuring that sensitive information is not illegally eavesdropped on.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a key distribution and communication adaptation method and related equipment for walkie-talkies. Background Technology

[0002] In existing secure communication technologies for walkie-talkies, to ensure the privacy and integrity of voice communication, pre-shared keys or session key negotiation based on centralized key distribution mechanisms are typically employed. A common approach is to pre-install a unified root key on the walkie-talkie at the factory. Before initiating communication, the device derives a session key from the root key using a static identity identifier, or a dispatch server centrally distributes encryption keys to both communicating parties. These methods are widely used in dedicated network communication scenarios such as public safety, transportation, and industrial dispatching, supporting end-to-end encrypted voice transmission in half-duplex mode to ensure sensitive information is not illegally eavesdropped on. Summary of the Invention

[0003] The main technical problem addressed in this application is to provide a key distribution and communication adaptation method and related equipment for walkie-talkies, which solves the technical problem of achieving end-to-end encrypted voice transmission in half-duplex mode to ensure that sensitive information is not illegally eavesdropped.

[0004] To address the aforementioned technical problems, this application employs a key distribution and communication adaptation method for walkie-talkies, comprising the following steps: The terminal identity feature code is extracted from the device identification information of the walkie-talkie terminal, and the terminal identity feature code is XORed with a preset random number seed to obtain the key generation factor. The pre-stored root key is distributed according to the key generation factor to obtain the session key ciphertext, and the session key ciphertext is transmitted to the target walkie-talkie terminal. The target walkie-talkie terminal decrypts the session key ciphertext based on the locally stored distributed key to obtain the session key plaintext. If the session key is successfully decrypted in plaintext and verified by the message authentication code, and the target walkie-talkie terminal detects that there is a voice communication request to be initiated, then the voice data frame to be sent is encrypted frame by frame based on the session key in plaintext to obtain an encrypted voice data frame, and the encrypted voice data frame is encapsulated into a communication data packet carrying a key version identifier for transmission. Furthermore, the step of extracting the terminal identity feature code from the device identification information of the walkie-talkie terminal includes: The device identification information is read from the secure storage area of ​​the walkie-talkie terminal, and the device identification information is parsed according to the preset field rules to obtain the device hardware identification field and the device registration identification field. The device hardware identifier field and the device registration identifier field are concatenated and combined to obtain an identifier combination sequence. The identifier combination sequence is then hashed and compressed to obtain the terminal identity feature code.

[0005] Furthermore, the step of performing an XOR operation between the terminal identity feature code and a preset random number seed to obtain the key generation factor includes: A preset random number seed is retrieved from the walkie-talkie key management module in advance, and the random number seed is timestamped to generate a timestamped random seed; The timestamped random seed is byte-normalized to make the byte length of the timestamped random seed consistent with the byte length of the terminal identity feature code, thus obtaining a normalized random seed; The terminal identity feature code and the regular random seed are XORed one by one according to the corresponding byte bits to obtain the initial factor sequence. The initial factor sequence is then subjected to cyclic shift verification to remove invalid and redundant bits in the sequence, thus obtaining the key generation factor.

[0006] Furthermore, the step of distributing the pre-stored root key according to the key generation factor to obtain the session key ciphertext includes: The root key is read from the pre-stored root key storage area in advance, and the root key is byte-padded according to the preset key length rules to obtain the standard root key; The key generation factor and the standard root key are fused according to a preset combination rule to obtain a fused key sequence. Then, an XOR operation is performed on two adjacent bytes in the fused key sequence to obtain an intermediate key sequence. Select an encryption key from a preset encryption key pool, and use the encryption key to perform symmetric encryption on the intermediate key sequence to obtain the session key ciphertext.

[0007] Furthermore, the process of decrypting the session key ciphertext using the locally stored distributed key to obtain the session key plaintext includes: The distributed key stored locally is read from the secure storage area of ​​the walkie-talkie terminal, and the distributed key is length aligned according to the byte length of the session key ciphertext to obtain the aligned distributed key. The session key ciphertext is symmetrically decrypted based on the aligned and distributed key to obtain a decryption key sequence, and a verification field and a key data field at a preset position are extracted from the decryption key sequence. The verification field is compared and verified with the pre-stored terminal identity feature code. After the verification is successful, the key data field is reassembled into bytes to obtain the session key plaintext.

[0008] Furthermore, the step of encrypting the plaintext of the session key into encrypted voice data frames, to obtain encrypted voice data frames, includes: Read the voice data frames to be sent sequentially from the voice encoding buffer of the walkie-talkie terminal, and extract the corresponding frame sequence number for each voice data frame to obtain the current frame sequence number; The plaintext of the session key is concatenated with the current frame sequence number to obtain the frame key seed, and the frame key seed is hashed and expanded to obtain the current frame encryption key. The voice data frame is encrypted in blocks based on the current frame encryption key to obtain frame ciphertext data. The frame ciphertext data is then encapsulated and combined with the current frame sequence number to obtain an encrypted voice data frame.

[0009] Furthermore, the step of concatenating the plaintext of the session key with the current frame sequence number to obtain the frame key seed includes: Extract the key front byte and key back byte from the session key plaintext according to the preset segmentation rules, and perform byte encoding conversion on the current frame sequence number to obtain the frame sequence number byte string, wherein the length of the frame sequence number byte string matches the length of the key front byte; The first byte of the key, the frame sequence number byte string, and the last byte of the key are concatenated in the order of first segment, middle segment, and last segment to obtain the concatenated original sequence. Then, the adjacent bytes in the concatenated original sequence are cross-obfuscated to obtain the obfuscated concatenated sequence. Cyclic redundancy check (CRC) is performed on the obfuscated concatenated sequence to generate a sequence check value, which is then appended to the end of the obfuscated concatenated sequence to obtain the frame key seed.

[0010] The present invention also provides a key distribution and communication adaptation device for walkie-talkies, comprising: The extraction module is used to extract the terminal identity feature code from the device identification information of the walkie-talkie terminal, and perform an XOR operation on the terminal identity feature code and a preset random number seed to obtain the key generation factor. The operation module is used to perform dispersion processing on the pre-stored root key according to the key generation factor to obtain the session key ciphertext, and transmit the session key ciphertext to the target walkie-talkie terminal, where the target walkie-talkie terminal performs decryption operation on the session key ciphertext based on the locally stored dispersion key to obtain the session key plaintext. The request module is configured to, if the plaintext of the session key is successfully decrypted and verified by the message authentication code, and the target walkie-talkie terminal detects that there is a voice communication request to be initiated, encrypt the voice data frame to be sent frame by frame based on the plaintext of the session key to obtain an encrypted voice data frame, and encapsulate the encrypted voice data frame into a communication data packet carrying a key version identifier for transmission.

[0011] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the above methods.

[0012] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any of the above methods.

[0013] The above scheme extracts the terminal identity feature code from the device identification information of the walkie-talkie terminal, and performs an XOR operation on the terminal identity feature code with a preset random number seed to obtain a key generation factor. Based on the key generation factor, the pre-stored root key is distributed to obtain the session key ciphertext, which is then transmitted to the target walkie-talkie terminal. The target walkie-talkie terminal decrypts the session key ciphertext based on its locally stored distributed key to obtain the session key plaintext. If the session key plaintext is successfully decrypted and verified by the message authentication code, and the target walkie-talkie terminal detects a pending voice communication request, it encrypts the voice data frames to be sent frame by frame based on the session key plaintext to obtain encrypted voice data frames. These encrypted voice data frames are then encapsulated into communication data packets carrying a key version identifier for transmission. This solves the technical problem of achieving end-to-end encrypted voice transmission in half-duplex mode, ensuring that sensitive information is not illegally eavesdropped on. It embeds the message authentication code verification mechanism into the key decryption process, ensuring that only session key plaintexts that pass integrity verification and have a legitimate source can be used for encryption, effectively preventing the risks of forged key injection and man-in-the-middle attacks. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a schematic diagram of the steps of a key distribution and communication adaptation method for a walkie-talkie in one embodiment of the present invention; Figure 2This is a structural block diagram of a key distribution and communication adaptation device for a walkie-talkie according to an embodiment of the present invention; Figure 3 This is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0016] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] Specifically, the key distribution and communication adaptation method for walkie-talkies in this embodiment includes the following steps: like Figure 1 As shown, Figure 1 This invention provides a method for key distribution and communication adaptation of a walkie-talkie, comprising the following steps: Step S1: Extract the terminal identity feature code from the device identification information of the walkie-talkie terminal, and perform an XOR operation between the terminal identity feature code and a preset random number seed to obtain the key generation factor.

[0019] Specifically, the device identification information of a walkie-talkie terminal is usually a unique code embedded in the hardware, such as an IMEI or MAC address consisting of 12 hexadecimal digits. When extracting the terminal identification feature code, the lower 32 bits are used as the basic data. The preset random number seed is generated by the system calling an internal random source to generate a 32-bit integer when a session is triggered. The two are then XORed bitwise, that is, the corresponding binary bits are logically set to "1 if different, 0 if the same," and the result is directly output as the key generation factor. For example, in a group call establishment process, if a terminal identification feature code is 0x8A3F2B1C and the random number seed is 0x5D9E4C7A, the key generation factor obtained after XORing is 0xD7AD6766. This value is subsequently used for the distribution calculation of the root key to ensure that each negotiation process is unique. The entire operation is completed within the secure encryption module, and no intermediate values ​​are exposed externally.

[0020] Step S2: Distribute the pre-stored root key according to the key generation factor to obtain the session key ciphertext, and transmit the session key ciphertext to the target walkie-talkie terminal. The target walkie-talkie terminal decrypts the session key ciphertext based on the locally stored distributed key to obtain the session key plaintext.

[0021] Specifically, using the key generation factor as input parameter and a pre-stored root key, the key derivation function in a block cipher algorithm performs a distribution process. For example, using AES-128 in CMAC mode, the root key is used as the master key, the key generation factor as the message input, and a fixed-length session key ciphertext is output. This process is completed in the initiator's security coprocessor, and the generated session key ciphertext is then transmitted to the target walkie-talkie terminal via a wireless channel. Upon receiving the ciphertext, the receiving end does not directly use the common algorithm to reverse-engineer it. Instead, it calls its locally stored distribution key—the same distribution key injected at the factory based on the same root key system as the sending end—to decrypt the received session key ciphertext. This typically employs the reverse decryption process corresponding to the derivation process, such as reconstructing the key block using the same CMAC structure, ultimately recovering the original session key plaintext. The entire process does not require the transmission of the root key itself, relying only on consistent key materials and algorithm logic at both ends.

[0022] Step S3: If the session key plaintext is successfully decrypted and verified by the message authentication code, and the target walkie-talkie terminal detects that there is a voice communication request to be initiated, then the voice data frame to be sent is encrypted frame by frame based on the session key plaintext to obtain an encrypted voice data frame, and the encrypted voice data frame is encapsulated into a communication data packet carrying a key version identifier for transmission.

[0023] Specifically, after decrypting the plaintext session key, the target walkie-talkie terminal immediately initiates an integrity verification process. It calculates the message authentication code using the pre-shared MAC key against the decrypted plaintext session key and compares it with the MAC value transmitted with the data. Verification is successful only if the two match. If the device has pending voice communication requests, such as a user pressing the PTT button to initiate a call, the system injects the plaintext session key into the audio encryption module. Each frame of acquired voice data, typically a 20ms encoded block, is sent to the encryption engine before transmission and encrypted frame-by-frame using AES-CTR mode to prevent leakage of a single frame from affecting overall security. The encrypted voice data frames are then packaged into communication data packets, with the currently used key version identifier added to the header. This version number is associated with the key generation factor and used by the receiver to quickly match decryption parameters. The entire encapsulation process is scheduled by the baseband processor and transmitted via the radio frequency unit.

[0024] In a specific embodiment, extracting the terminal identity feature code from the device identification information of the walkie-talkie terminal includes: The device identification information is read from the secure storage area of ​​the walkie-talkie terminal, and the device identification information is parsed according to the preset field rules to obtain the device hardware identification field and the device registration identification field. The device hardware identifier field and the device registration identifier field are concatenated and combined to obtain an identifier combination sequence. The identifier combination sequence is then hashed and compressed to obtain the terminal identity feature code.

[0025] Specifically, the device identification information of walkie-talkie terminals is usually stored in a secure storage area in a fixed form. This area is mostly located inside the TPM or SE chip and has the ability to prevent physical reading and logical tampering. When the system starts the key negotiation process, it first reads the original identification data from this area through the trusted firmware calling the underlying interface. Its length is generally 20 bytes, and the structure is divided according to preset field rules. Specifically, the first 12 bytes are defined as the device hardware identification field. This part often corresponds to the MAC address or the unique serial number of the RF chip burned in when the device leaves the factory, such as "00:1A:2B:3C:4D:5E:5F:6A:7B:8C:9D:AE"; the next 8 bytes are used as the device registration identification field, which is used to record the logical number assigned by the scheduling server after the terminal completes network access authentication in the private network system, such as "REG0001F", which has certain business management attributes. These two fields are concatenated in sequence to form a continuous identification combination sequence with a total length of 20 bytes. This process does not involve encoding conversion or padding operations, but is directly concatenated by byte stream. Next, the identifier combination sequence is hashed and compressed using the SHA-256 algorithm for one-way hashing. The input is the aforementioned 20-byte sequence, and the output is a 32-byte fixed-length digest value. To accommodate the input length requirements of the subsequent key derivation module, the first 16 bytes (128 bits) of this digest are used as the final terminal identity feature code. The entire calculation process is completed in a secure, isolated environment; neither the original fields nor the intermediate results reside in plaintext in ordinary memory. For example, during a cross-group call setup, a police walkie-talkie uses this mechanism to generate a feature code, ensuring that even if multiple terminals share the same hardware model, they can generate different key derivation starting points due to differences in registration identifiers, thus enhancing the impersonation resistance of individual identities.

[0026] In a specific embodiment, the step of performing an XOR operation between the terminal identity feature code and a preset random number seed to obtain the key generation factor includes: A preset random number seed is retrieved from the walkie-talkie key management module in advance, and the random number seed is timestamped to generate a timestamped random seed; The timestamped random seed is byte-normalized to make the byte length of the timestamped random seed consistent with the byte length of the terminal identity feature code, thus obtaining a normalized random seed; The terminal identity feature code and the regular random seed are XORed one by one according to the corresponding byte bits to obtain the initial factor sequence. The initial factor sequence is then subjected to cyclic shift verification to remove invalid and redundant bits in the sequence, thus obtaining the key generation factor.

[0027] Specifically, the generation of the key generation factor begins with the retrieval and enhancement of a preset random number seed. This random number seed is not a fixed value, but is dynamically provided by the key management module inside the walkie-talkie before each communication session is triggered. It is usually derived from a 32-byte data block generated by a hardware true random number generator (TRNG) combined with the system entropy pool. To introduce a time dimension to prevent replay attacks, a timestamp is first appended to the random number seed. Specifically, the current UTC time is converted to an 8-byte integer value with second-level precision and appended to the end of the original seed to form a timestamped random seed. For example, if the time of a police walkie-talkie group call establishment is 2026-02-05 14:30:15, the corresponding timestamp 0x138A7B9F is appended to the seed, making the total length 40 bytes. Next, byte normalization is performed. Since the terminal identification feature code is 128 bits, or 16 bytes, the above 40-byte timestamped random seed needs to be compressed to the same length. This process does not use simple truncation. Instead, it first performs a SHA-1 hash operation on the entire 40-byte sequence, outputting a 20-byte digest. Then, it takes the first 16 bytes as a regularized random seed to ensure a uniform distribution of information entropy. At this point, the regularized random seed and the terminal identity feature code have the same byte length, satisfying the bitwise operation condition. The two then enter the XOR operation stage, performing a logical XOR operation sequentially from bit 0 to bit 15 in byte order. That is, the byte value at each position is calculated in binary with "0 for the same, 1 for different", resulting in a 16-byte initial factor sequence. For example, if a byte of the feature code is 0xA3 and the corresponding regularized seed byte is 0x5C, the XOR result is 0xFF. This sequence cannot be used directly yet and needs further cyclic shift verification processing. Specifically, it is grouped into 4-byte units, and each group is left-circularly shifted by 3 bits. It is then checked whether there are 8 or more consecutive identical bits or all zeros after the shift. If so, they are considered invalid redundant bits and are discarded. The remaining valid bits are recombined to form the final key generation factor. This process effectively eliminates the risk of weak keys due to random source bias, improving the security of subsequent key distribution. The entire process is completed within a secure coprocessor, and intermediate data does not appear in main memory.

[0028] In a specific embodiment, the step of dispersing the pre-stored root key according to the key generation factor to obtain the session key ciphertext includes: The root key is read from the pre-stored root key storage area in advance, and the root key is byte-padded according to the preset key length rules to obtain the standard root key; The key generation factor and the standard root key are fused according to a preset combination rule to obtain a fused key sequence. Then, an XOR operation is performed on two adjacent bytes in the fused key sequence to obtain an intermediate key sequence. Select an encryption key from a preset encryption key pool, and use the encryption key to perform symmetric encryption on the intermediate key sequence to obtain the session key ciphertext.

[0029] Specifically, the generation of the session key ciphertext begins with reading and standardizing the pre-stored root key. This root key is typically stored in the walkie-talkie's security chip in 128-bit or 256-bit lengths and marked as non-exportable. Before use, the original data must be read from the root key storage area. If its length does not meet the input requirements of subsequent algorithms, it is padded with bytes according to a preset key length rule. For example, when using AES-128 as the underlying encryption algorithm, the input key is required to be 16 bytes. If the original root key is 12 bytes, it is padded with four fixed values ​​of 0x00 at the end to form a standard root key. This step ensures the uniformity of key structure across different batches of devices. Next, the fusion processing stage begins, where the previously obtained key generation factor (16 bytes) and the standard root key (16 bytes) are interleaved according to a preset combination rule. A common method is to place the root key bytes in odd-numbered positions and the key generation factor bytes in even-numbered positions, forming a 32-byte fused key sequence. For example, positions 0, 2, 4… are filled with bytes 0, 1, 2… of the root key, and positions 1, 3, 5… are filled with bytes corresponding to the key generation factors. This sequence is not used directly for encryption, but is further subjected to internal perturbation processing. Specifically, adjacent pairs of bytes in the fused key sequence are XORed sequentially: byte 0 is XORed with byte 1, and the result replaces the original byte 1; byte 2 is XORed with byte 3, and the result replaces byte 3, and so on, until the last pair of bytes is processed, ultimately outputting an intermediate key sequence of equal length. This process enhances the avalanche effect of the key material, causing small input differences to lead to significant output changes. After the intermediate key sequence is generated, it does not immediately participate in voice encryption, but is encapsulated as an object to be protected. The system randomly selects an available encryption key from a preset encryption key pool. This key pool has multiple 128-bit keys pre-programmed, numbered from K0 to K7. Each selection follows a polling or pseudo-random strategy to avoid long-term use of a single protection key. Assuming K3 is selected this time, with a value of 0x3A7F...C8E2, then AES-ECB encryption is performed on the intermediate key sequence using this encryption key, and the output is the session key ciphertext. The entire process is completed in a trusted execution environment, and neither the standard root key nor the intermediate sequence is exposed in plaintext form in ordinary memory space, ensuring a secure closed loop in the key distribution process. This multi-layered nested processing mechanism effectively prevents the risk of the entire network key system collapsing due to a single point of leakage in police trunking communication.

[0030] In a specific embodiment, the step of decrypting the ciphertext of the session key based on the locally stored distributed key to obtain the plaintext of the session key includes: The distributed key stored locally is read from the secure storage area of ​​the walkie-talkie terminal, and the distributed key is length aligned according to the byte length of the session key ciphertext to obtain the aligned distributed key. The session key ciphertext is symmetrically decrypted based on the aligned and distributed key to obtain a decryption key sequence, and a verification field and a key data field at a preset position are extracted from the decryption key sequence. The verification field is compared and verified with the pre-stored terminal identity feature code. After the verification is successful, the key data field is reassembled into bytes to obtain the session key plaintext.

[0031] Specifically, after receiving the ciphertext of the session key, the target walkie-talkie terminal initiates a local decryption process. First, it reads the pre-programmed locally stored distributed key from its secure storage area. This key is injected by the key management system during device registration and is unique and cannot be read externally. Since the length of the session key ciphertext may vary depending on the encryption algorithm mode (e.g., 16 bytes under AES-128-ECB, 32 bytes under AES-256), the original distributed key needs to be length-adapted. Therefore, length alignment is performed based on the actual byte length of the current session key ciphertext. If the distributed key is shorter than the target length, it is padded to the same length using PKCS#7; if it is too long, the excess bytes are truncated, ultimately generating an aligned distributed key of the same length as the ciphertext. For example, in a cross-group voice call, if the received session key ciphertext is 16 bytes and the original length of the local distributed key is 20 bytes, the first 16 bytes are directly truncated as the aligned distributed key for subsequent operations. Next, the aligned and distributed key is used to perform symmetric decryption on the session key ciphertext. The underlying AES decryption engine is called, operating in the same mode as the sender, such as ECB or CBC mode (the initialization vector can be set to all zeros by default). The output is the decryption key sequence, with the same length as the original input. This sequence is not used directly as the session key but contains multiple logical fields. The system extracts data from specific positions according to a preset format; for example, bytes 0 to 11 are defined as the key data field, and bytes 12 to 15 are the check field. The content of the check field is actually a hash fragment related to the terminal's identity feature code embedded by the sender before encryption. To verify the legitimacy of the source, the receiver compares the extracted check field with its locally calculated terminal identity feature code; only if they match completely is it considered successful. If the verification is successful, it means that the key packet was indeed generated for the local machine and has not been tampered with. At this point, the key data field undergoes byte reassembly—this process follows the mapping rules set at the factory, such as reversing the original sequence in 4-byte units and then interleaving the bytes, ultimately outputting a stable 16-byte session key plaintext. The entire process is completed within the security coprocessor, avoiding the risk of intermediate data leakage and ensuring that only legitimate terminals can recover the correct communication key.

[0032] In a specific embodiment, the step of encrypting the voice data frames to be sent frame by frame based on the plaintext of the session key to obtain encrypted voice data frames includes: Read the voice data frames to be sent sequentially from the voice encoding buffer of the walkie-talkie terminal, and extract the corresponding frame sequence number for each voice data frame to obtain the current frame sequence number; The plaintext of the session key is concatenated with the current frame sequence number to obtain the frame key seed, and the frame key seed is hashed and expanded to obtain the current frame encryption key. The voice data frame is encrypted in blocks based on the current frame encryption key to obtain frame ciphertext data. The frame ciphertext data is then encapsulated and combined with the current frame sequence number to obtain an encrypted voice data frame.

[0033] Specifically, the encryption processing of voice data begins after the walkie-talkie enters PTT (Push-to-Talk) mode. The system reads compressed voice data frames sequentially from the voice encoding buffer. Each frame corresponds to a 20ms AMBE or CELP encoding block, typically 16 bytes in length. When processing each frame, its sequence number within the current call cycle is extracted as the current frame sequence number. This sequence number is automatically incremented by the baseband processor during frame generation, starting at 0x0001 and incrementing by one for each subsequent frame. For example, the current frame sequence number for the third transmitted data frame is 0x0003. This sequence number is not directly used for encryption but is concatenated with the negotiated session key plaintext. Specifically, the session key plaintext (16 bytes) and the current frame sequence number (2 bytes) are concatenated into an 18-byte continuous byte stream, forming the frame key seed. Because this seed has an irregular length, it is unsuitable for direct use as an encryption key and requires further processing. Next, a hash expansion process is performed using the HMAC-SHA256 algorithm. A fixed key K_ext is used as the key input, and the frame key seed is used as the message input. A 32-byte digest is calculated, and the first 16 bytes are truncated as the encryption key for the current frame. This mechanism ensures that each frame uses a different encryption key, making it difficult for an attacker to deduce the master key through comparison even if they intercept multiple ciphertext frames. After obtaining the encryption key for the current frame, it is immediately used for block encryption in AES-CTR mode. The voice data frame is used as plaintext input, along with a counter that increments with each frame (the initial value can be bound to the call ID), outputting ciphertext data of equal length. After encryption, the ciphertext is not transmitted separately. Instead, the ciphertext data is encapsulated and combined with the original current frame sequence number to form a new data structure. The ciphertext data is placed in the payload area, and the current frame sequence number is filled into the header identifier field, together forming the encrypted voice data frame. This design facilitates rapid frame order identification and key recovery at the receiving end, while also supporting packet loss detection and reordering recovery. The entire process is executed in a closed loop within the audio subsystem, with real-time processing frame by frame to avoid the accumulation of voice delays, ensuring encryption real-time performance and anti-eavesdropping capabilities in police trunking communications.

[0034] In a specific embodiment, the step of concatenating the plaintext of the session key with the current frame sequence number to obtain the frame key seed includes: Extract the key front byte and key back byte from the session key plaintext according to the preset segmentation rules, and perform byte encoding conversion on the current frame sequence number to obtain the frame sequence number byte string, wherein the length of the frame sequence number byte string matches the length of the key front byte; The first byte of the key, the frame sequence number byte string, and the last byte of the key are concatenated in the order of first segment, middle segment, and last segment to obtain the concatenated original sequence. Then, the adjacent bytes in the concatenated original sequence are cross-obfuscated to obtain the obfuscated concatenated sequence. Cyclic redundancy check (CRC) is performed on the obfuscated concatenated sequence to generate a sequence check value, which is then appended to the end of the obfuscated concatenated sequence to obtain the frame key seed.

[0035] Specifically, the concatenation process of the session key plaintext and the current frame sequence number is performed in real time before voice encryption, with the aim of generating a key seed with frame uniqueness. At the start of the operation, the 16-byte session key plaintext is first split according to a preset segmentation rule, taking the first 8 bytes as the key's front segment bytes and the last 8 bytes as the key's back segment bytes, without reserving any empty spaces or padding data in between. Simultaneously, the current frame sequence number, usually a 2-byte integer value, needs to be converted to byte form and its length adjusted to match the key's front segment bytes. Specifically, this sequence number is expanded into two bytes in big-endian format, and then six zero bytes are added to its high-order bits to form an 8-byte frame sequence number byte string. For example, the sequence number 0x0005 corresponding to frame 5 becomes "00 00 00 00 00 00 00 05" after encoding expansion. Next, the data is concatenated. The three parts are combined in the order of first segment, middle segment, and last segment: first, the key's first byte, then the frame sequence number byte string, and finally the key's last byte, forming a continuous 24-byte concatenated original sequence. Although this sequence incorporates the master key and frame sequence information, its structure is still relatively regular, making it vulnerable to pattern analysis attacks. Therefore, a cross-obfuscation operation is introduced. Starting from the beginning of the sequence, every two adjacent bytes are grouped together. The value of the preceding byte is XORed with the following byte, and the result overwrites the original following byte. This process continues until the entire sequence is processed, resulting in the obfuscated concatenated sequence. This operation breaks the boundary characteristics between the original data blocks, making the output closer to a random distribution. Cyclic redundancy check (CRC) is then performed on the obfuscated concatenated sequence. A 2-byte sequence check value is generated using the standard CRC-16 algorithm, primarily used to detect unexpected errors in subsequent transmission or computation. This check value is not discarded but directly appended to the end of the obfuscated concatenated sequence, forming the final 26-byte frame key seed. This structure not only serves for subsequent key derivation but also implicitly includes a certain degree of integrity protection, assisting the receiver in determining whether the frame synchronization status is abnormal. The entire process is executed within the audio security module, and intermediate products do not appear in memory areas accessible through debuggable interfaces, ensuring the security of key materials. In actual police intercom communication, this mechanism effectively prevents the risk of voice playback or forgery due to frame key duplication or predictability.

[0036] Please see Figure 2 , Figure 2 This is a schematic diagram of the framework of an embodiment of the key distribution and communication adaptation device for a walkie-talkie according to this application. Figure 2 As shown, the key distribution and communication adaptation device for the walkie-talkie includes an extraction module 1, used to extract a terminal identity feature code from the device identification information of the walkie-talkie terminal, and perform an XOR operation on the terminal identity feature code with a preset random number seed to obtain a key generation factor; an operation module 2, used to perform dispersion processing on a pre-stored root key according to the key generation factor to obtain a session key ciphertext, and transmit the session key ciphertext to the target walkie-talkie terminal, where the target walkie-talkie terminal performs a decryption operation on the session key ciphertext based on a locally stored dispersion key to obtain a session key plaintext; and a request module 3, used to, if the session key plaintext is successfully decrypted and verified by a message authentication code, and the target walkie-talkie terminal detects that there is a voice communication request to be initiated, then perform frame-by-frame encryption processing on the voice data frame to be sent based on the session key plaintext to obtain an encrypted voice data frame, and encapsulate the encrypted voice data frame into a communication data packet carrying a key version identifier for transmission.

[0037] Reference Figure 3 This invention also provides a computer device whose internal structure can be as follows: Figure 3 As shown, the computer device includes a processor, memory, display screen, input device, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores the data corresponding to this embodiment. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described method.

[0038] Those skilled in the art will understand that Figure 3 The structures shown are merely block diagrams of some structures related to the present invention and do not constitute a limitation on the computer devices on which the present invention is applied.

[0039] An embodiment of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. It is understood that the computer-readable storage medium in this embodiment can be a volatile readable storage medium or a non-volatile readable storage medium.

[0040] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the present invention and embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM, etc.

[0041] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0042] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities can be referred to each other. For the sake of brevity, they will not be repeated here.

[0043] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0044] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0045] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0046] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0047] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

Claims

1. A key distribution and communication adaptation method for a walkie-talkie, characterized in that, Includes the following steps: The terminal identity feature code is extracted from the device identification information of the walkie-talkie terminal, and the terminal identity feature code is XORed with a preset random number seed to obtain the key generation factor. The pre-stored root key is distributed according to the key generation factor to obtain the session key ciphertext, and the session key ciphertext is transmitted to the target walkie-talkie terminal. The target walkie-talkie terminal decrypts the session key ciphertext based on the locally stored distributed key to obtain the session key plaintext. If the session key is successfully decrypted in plaintext and verified by the message authentication code, and the target walkie-talkie terminal detects that there is a voice communication request to be initiated, then the voice data frame to be sent is encrypted frame by frame based on the session key in plaintext to obtain an encrypted voice data frame, and the encrypted voice data frame is encapsulated into a communication data packet carrying a key version identifier for transmission.

2. The key distribution and communication adaptation method for a walkie-talkie according to claim 1, characterized in that, The step of extracting the terminal identity feature code from the device identification information of the walkie-talkie terminal includes: The device identification information is read from the secure storage area of ​​the walkie-talkie terminal, and the device identification information is parsed according to the preset field rules to obtain the device hardware identification field and the device registration identification field. The device hardware identifier field and the device registration identifier field are concatenated and combined to obtain an identifier combination sequence. The identifier combination sequence is then hashed and compressed to obtain the terminal identity feature code.

3. The key distribution and communication adaptation method for a walkie-talkie according to claim 1, characterized in that, The step of performing an XOR operation between the terminal identity feature code and a preset random number seed to obtain the key generation factor includes: A preset random number seed is retrieved from the walkie-talkie key management module in advance, and the random number seed is timestamped to generate a timestamped random seed; The timestamped random seed is byte-normalized to make the byte length of the timestamped random seed consistent with the byte length of the terminal identity feature code, thus obtaining a normalized random seed; The terminal identity feature code and the regular random seed are XORed one by one according to the corresponding byte bits to obtain the initial factor sequence. The initial factor sequence is then subjected to cyclic shift verification to remove invalid and redundant bits, thus obtaining the key generation factor.

4. The key distribution and communication adaptation method for a walkie-talkie according to claim 1, characterized in that, The step of dispersing the pre-stored root key according to the key generation factor to obtain the session key ciphertext includes: The root key is read from the pre-stored root key storage area in advance, and the root key is byte-padded according to the preset key length rules to obtain the standard root key; The key generation factor and the standard root key are fused according to a preset combination rule to obtain a fused key sequence. Then, an XOR operation is performed on two adjacent bytes in the fused key sequence to obtain an intermediate key sequence. Select an encryption key from a preset encryption key pool, and use the encryption key to perform symmetric encryption on the intermediate key sequence to obtain the session key ciphertext.

5. The key distribution and communication adaptation method for a walkie-talkie according to claim 1, characterized in that, The session key ciphertext is decrypted using the locally stored distributed key to obtain the session key plaintext, including: The distributed key stored locally is read from the secure storage area of ​​the walkie-talkie terminal in advance, and the distributed key is length aligned according to the byte length of the session key ciphertext to obtain an aligned distributed key; The session key ciphertext is symmetrically decrypted based on the aligned and distributed key to obtain a decryption key sequence, and a verification field and a key data field at a preset position are extracted from the decryption key sequence. The verification field is compared and verified with the pre-stored terminal identity feature code. After the verification is successful, the key data field is reassembled into bytes to obtain the session key plaintext.

6. The key distribution and communication adaptation method for a walkie-talkie according to claim 1, characterized in that, The step of encrypting the plaintext of the session key into encrypted voice data frames, resulting in encrypted voice data frames, includes: Read the voice data frames to be sent sequentially from the voice encoding buffer of the walkie-talkie terminal, and extract the corresponding frame sequence number for each voice data frame to obtain the current frame sequence number; The plaintext of the session key is concatenated with the current frame sequence number to obtain the frame key seed, and the frame key seed is hashed and expanded to obtain the current frame encryption key. The voice data frame is encrypted in blocks based on the current frame encryption key to obtain frame ciphertext data. The frame ciphertext data is then encapsulated and combined with the current frame sequence number to obtain an encrypted voice data frame.

7. The key distribution and communication adaptation method for a walkie-talkie according to claim 6, characterized in that, The step of concatenating the plaintext of the session key with the current frame sequence number to obtain the frame key seed includes: Extract the key front byte and key back byte from the session key plaintext according to the preset segmentation rules, and perform byte encoding conversion on the current frame sequence number to obtain the frame sequence number byte string, wherein the length of the frame sequence number byte string matches the length of the key front byte; The first byte of the key, the frame sequence number byte string, and the last byte of the key are concatenated in the order of first segment, middle segment, and last segment to obtain the concatenated original sequence. Then, the adjacent bytes in the concatenated original sequence are cross-obfuscated to obtain the obfuscated concatenated sequence. Cyclic redundancy check (CRC) is performed on the obfuscated concatenated sequence to generate a sequence check value, which is then appended to the end of the obfuscated concatenated sequence to obtain the frame key seed.

8. A key distribution and communication adaptation device for a walkie-talkie, characterized in that, include: The extraction module is used to extract the terminal identity feature code from the device identification information of the walkie-talkie terminal, and perform an XOR operation on the terminal identity feature code and a preset random number seed to obtain the key generation factor. The operation module is used to perform dispersion processing on the pre-stored root key according to the key generation factor to obtain the session key ciphertext, and transmit the session key ciphertext to the target walkie-talkie terminal, where the target walkie-talkie terminal performs decryption operation on the session key ciphertext based on the locally stored dispersion key to obtain the session key plaintext. The request module is configured to, if the plaintext of the session key is successfully decrypted and verified by the message authentication code, and the target walkie-talkie terminal detects that there is a voice communication request to be initiated, encrypt the voice data frame to be sent frame by frame based on the plaintext of the session key to obtain an encrypted voice data frame, and encapsulate the encrypted voice data frame into a communication data packet carrying a key version identifier for transmission.

9. A computer device, characterized in that, The device includes a memory and a processor that are coupled to each other. The memory stores program instructions, and the processor executes the program instructions to implement the key distribution and communication adaptation method for a walkie-talkie according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The device stores program instructions that can be executed by a processor, the program instructions being used to implement the key distribution and communication adaptation method for a walkie-talkie according to any one of claims 1 to 7.

Images