Auracast broadcast privacy protection system supporting key distribution and access control

Abstract

The invention belongs to the technical field of wireless digital broadcast communication security, and relates to an Auracast broadcast privacy protection system supporting key distribution and access control, which comprises a channel establishment and authentication module for establishing an out-of-band security control channel; the precursor key issuing module is used for issuing a static session precursor key to the target receiving equipment and the broadcast source equipment through channel encryption; the session key generation module is used for deriving a slice session key in combination with the public synchronization factor and the precursor key; the data packaging and sending module is used for encrypting the audio by using the slice session key, assembling a data frame and sending the data frame; the local key synthesis module is used for extracting a synchronization factor and locally synthesizing a slice session key; the audio stream analysis and output module is used for decrypting the data and managing a key life cycle; and the secret key life cycle management module is used for monitoring the state through a channel and executing erasing. According to the invention, the problem of realizing low-delay dynamic encryption and instant permission revocation without relying on periodic key redistribution in wireless broadcasting is solved.

Description

Auracast broadcast privacy protection system supporting key distribution and access control Technical Field

[0001] This invention belongs to the technical field of wireless digital broadcast communication security, and relates to the Auracast broadcast privacy protection system that supports key distribution and access control. Background Technology

[0002] Wireless digital broadcast communication systems typically transmit signals through open wireless channels, such as Bluetooth Auracast audio broadcasting technology, where receiving devices within the signal coverage area can capture broadcast data. Because conventional broadcast protocols lack built-in identity-based access control mechanisms, audio data is usually sent in plaintext, making it difficult for the system to effectively distinguish between authorized and unauthorized devices. This leads to risks of unauthorized users accessing services or privacy data being leaked.

[0003] To achieve controlled access to broadcast content, existing technologies primarily employ two encryption schemes. The first scheme distributes a unified, shared, static encryption key to all authorized devices upon initial access or service subscription. Both the broadcast source and receiving devices use this fixed key for encryption and decryption. The second scheme establishes a centralized management architecture, where administrators periodically distribute updated keys to all authorized devices via network connections, attempting to maintain communication security through dynamically changing keys.

[0004] However, schemes using shared static encryption keys suffer from insufficient forward security; a key leak on a single device could compromise the entire broadcast session's history and future content, posing a persistent security risk. On the other hand, schemes using periodic key distribution are prone to delays in distributing and updating new keys when implementing forced permission revocation or handling large groups of devices, making it difficult to guarantee the continuity of broadcast services. Furthermore, this scheme is highly dependent on stable network connections, increasing the system's management load and communication overhead. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides an Auracast broadcast privacy protection system that supports key distribution and access control.

[0006] The Auracast broadcast privacy protection system, supporting key distribution and access control, includes: a channel establishment and authentication module, where the access control server verifies the identity of the target receiving device initiating the connection and establishes an out-of-band security control channel independent of the broadcast channel after successful verification; a pre-session key distribution module, where the access control server generates a static session pre-session key and encrypts and distributes it to the secure storage area of ​​the target receiving device and to the broadcast source device via the out-of-band security control channel; a session key generation module, where the broadcast source device generates a public synchronization factor when processing the current time slice and combines it with the locally synchronized session pre-session key to generate a slice session key using a key derivation function; and a data encapsulation and transmission module, where the broadcast source device... The audio data is encrypted using a segmented session key, and the public synchronization factor is embedded in the protocol header. This is then assembled into a synthetic broadcast data frame and sent. A local key synthesis module is used by the target receiving device to parse the received synthetic broadcast data frame to extract the public synchronization factor and uses the locally stored session pre-key to synthesize a segmented session key. An audio stream parsing and output module is used by the target receiving device to decrypt the encrypted data in the synthetic broadcast data frame using the locally synthesized segmented session key and output it for playback. The key is discarded at the end of the current time segment. A key lifecycle management module is used by the access control server and the target receiving device to perform status monitoring through an out-of-band security control channel. If an unauthorized state is detected or there is no response after timeout, a key erasure operation is performed.

[0007] A further embodiment of the present invention includes a channel establishment and authentication module, which performs the following operations: the access control server responds to the connection request of the target receiving device and initiates a handshake process based on the transport layer security protocol; the access control server and the target receiving device exchange and verify digital certificates to verify the legality of the device identifier; an end-to-end bidirectional encrypted communication link is established based on the session key negotiated through the handshake, serving as an out-of-band security control channel, and the device's initial connection timestamp and permission level are recorded.

[0008] A further embodiment of the present invention includes a pre-session key distribution module, which performs the following operations: the access control server uses a cryptographically secure pseudo-random number generator to generate a binary data block that does not have the ability to directly decrypt audio, as a session pre-session key; the session pre-session key and key version identifier are encapsulated and transmitted to the target receiving device through an out-of-band secure control channel; the target receiving device writes the received session pre-session key into a hardware-isolated trusted execution environment or secure element, and sets permission conditions that only allow specific key-derived processes to access it.

[0009] A further embodiment of the present invention includes a session key generation module, which performs the following operations: the broadcast source device reads the timestamp of the clock or the value of the hardware loop counter, and formats and generates a public synchronization factor that dynamically changes over time; it calls a preset key derivation function based on a hash message authentication code; it takes the locally stored session precursor key as the key input, the public synchronization factor as the message input, performs a one-way hash operation, and outputs a binary data block as the slice session key.

[0010] A further embodiment of the present invention includes a data encapsulation and transmission module, which performs the following steps: encrypting the original audio data using a slice session key and employing the CCM mode of the AES encryption standard to generate an encrypted audio payload and a message authentication code; writing the public synchronization factor into the extended broadcast header or manufacturer-specific data field of the broadcast protocol data unit; concatenating the header carrying the public synchronization factor with the encrypted audio payload to generate a composite broadcast data frame, and transmitting it through the Bluetooth Low Energy broadcast channel.

[0011] A further embodiment of the present invention includes a local key synthesis module, which performs the following steps: the target receiving device captures a synthesized broadcast data frame through a broadcast scanning unit and parses the extended broadcast header to separate the public synchronization factor; it calls the session pre-key from the secure storage area and loads a key derivation function consistent with the broadcast source device; it performs real-time calculations on the session pre-key and the extracted public synchronization factor, and outputs the calculation result as the locally synthesized slice session key.

[0012] A further embodiment of the present invention includes an audio stream parsing and output module, which performs the following steps: loading the locally synthesized slice session key into the decryption algorithm module to decrypt the encrypted audio payload in the synthesized broadcast data frame; comparing the verification value generated during the decryption process with the message authentication code in the data frame, and if they match, determining that the integrity verification has passed; transmitting the decoded audio signal to the audio output unit, and clearing the currently used slice session key from memory when the next data frame containing a different public synchronization factor is detected.

[0013] A further embodiment of the present invention includes a key lifecycle management module, which performs the following operations: the access control server sends a heartbeat detection command to the target receiving device through an out-of-band security control channel and starts a response timeout timer; if no response is received within a preset time limit or a permission revocation command is received, the server sends a key erasure command through the out-of-band security control channel; the target receiving device responds to the key erasure command, or if no confirmation is received from the server when the local security countdown timer expires, it forcibly performs a physical overwrite and erasure of the locally stored session pre-key.

[0014] A further aspect of the present invention includes the following steps in generating the encrypted audio payload: reading the packet sequence number of the current audio data frame; combining the public synchronization factor with the packet sequence number; and mapping the combined data to the initial vector field required by the AES-CCM mode.

[0015] In a further embodiment of the present invention, after the target receiving device returns a key reception confirmation receipt to the access control server, it calls the operating system interface to set storage permissions for the address of the storage session predecessor key, allowing only trusted applications to access it.

[0016] In summary, the present invention offers the following beneficial technical effects: 1. By establishing an out-of-band security control channel independent of the broadcast channel, the present invention completes device authentication and the distribution of static session pre-keys during the session initialization phase. This mechanism separates the transmission process of the high-entropy key seed from the public broadcast channel, avoiding channel congestion and interaction delays caused by new device additions or key updates during the broadcast process, thereby achieving secure key pre-setting without consuming broadcast bandwidth.

[0017] 2. This invention generates a public synchronization factor for each time slice through a broadcast source device and derives a slice session key that is only valid for the current slice by combining it with the locally stored session precursor key. Since the core static precursor key does not participate in broadcast transmission and the encryption key changes dynamically with data frames, even if an attacker intercepts the public synchronization factor or cracks the slice key at a certain moment, it is difficult to reverse-engineer the session precursor key or decrypt historical and future data of other time slices, thereby improving the security of the communication system.

[0018] 3. This invention enables the receiving device to extract the public synchronization factor from broadcast data frames and independently synthesize the decryption key using a locally pre-stored session pre-key and a consistent algorithm. This method eliminates the need for real-time interactive handshakes or negotiations between the broadcasting and receiving ends, achieving synchronous updates of the decryption key, effectively reducing the communication overhead caused by key negotiation, and meeting the technical requirements for low-latency playback of audio streams.

[0019] 4. This invention utilizes an out-of-band secure control channel for heartbeat monitoring and combines it with a local secure countdown mechanism to forcibly erase the device's local session pre-key when the device is detected to be offline, has timed out, or has received a revocation command. This mechanism allows administrators to independently revoke access permissions for a single device without interrupting the overall broadcast service or redistributing keys to all devices, thus improving the system's control over unauthorized access and management efficiency. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. The drawings are used to provide a further understanding of the present invention.

[0021] Figure 1 is a schematic diagram of the framework in an embodiment of this application.

[0022] Figure 2 is a flowchart of an embodiment of this application. Detailed Implementation

[0023] The present invention will now be described in detail with reference to Figures 1-2.

[0024] Referring to Figures 1-2, this invention proposes an Auracast broadcast privacy protection system supporting key distribution and access control, comprising the following modules: a channel establishment and authentication module, where the access control server verifies the identity of the target receiving device initiating the connection and establishes an out-of-band security control channel independent of the broadcast channel after successful verification; a pre-session key distribution module, where the access control server generates a static session pre-session key and encrypts and distributes it to the secure storage area of ​​the target receiving device and to the broadcast source device via the out-of-band security control channel; a session key generation module, where the broadcast source device generates a public synchronization factor when processing the current time slice and, in conjunction with the locally synchronized session pre-session key, generates a slice session key using a key derivation function; and data encapsulation and transmission. The broadcast source device encrypts audio data using the segment session key and embeds the public synchronization factor into the protocol header, assembling it into a synthetic broadcast data frame before sending. The local key synthesis module parses the received synthetic broadcast data frame to extract the public synchronization factor and uses the locally stored session pre-key to synthesize the segment session key locally. The audio stream parsing and output module decrypts the encrypted data in the synthetic broadcast data frame using the locally synthesized segment session key and outputs it for playback, discarding the key at the end of the current time segment. The key lifecycle management module performs status monitoring between the access control server and the target receiving device through an out-of-band security control channel, and performs key erasure operations when an unauthorized state is determined or a timeout occurs.

[0025] In one embodiment of the present invention, the channel establishment and authentication module is used to perform the following operations: the access control server responds to the connection request of the target receiving device and initiates a handshake process based on the transport layer security protocol; the access control server and the target receiving device exchange and verify digital certificates to verify the legality of the device identifier; an end-to-end bidirectional encrypted communication link is established based on the session key negotiated by the handshake, which serves as an out-of-band security control channel, and the initial connection timestamp and permission level of the device are recorded.

[0026] Specifically, the access control server pre-starts a network service process at the local operating system level. This process binds to and listens on a fixed TCP port, such as port 443, to receive connection requests from target receiving devices. When a target receiving device attempts to access the network, its network communication module initiates a TCP connection request to the access control server at the specified IP address and port.

[0027] Upon receiving the request, the network service process of the access control server immediately initiates a preset authentication protocol. In this embodiment, the preset authentication protocol is a client-server two-way certificate authentication mechanism based on the Public Key Infrastructure (PKI) system, ensuring that the identities of both communicating parties are trustworthy. This protocol is specifically implemented as a handshake process based on the Transport Layer Security (TLS) 1.3 protocol. In this process, the access control server first sends its own X.509 digital certificate to the target receiving device. The target receiving device uses its built-in trusted root certificate authority list to verify the legitimacy of the server certificate, including the certificate signature, validity period, and certificate revocation list status. After successful verification, the target receiving device also sends its device-specific client certificate back to the access control server. This certificate contains a unique device identifier, such as a 128-bit universally unique identifier. The access control server verifies the signature and validity period of the client certificate and queries its internal authorized device list database to confirm the legitimacy of the device identifier, thus completing the two-way authentication.

[0028] After successful authentication, both parties establish a full-duplex, end-to-end encrypted communication link over the established TCP connection based on the session key negotiated during the handshake. This link constitutes the out-of-band secure control channel of this invention. It should be noted that the out-of-band secure control channel refers to an encrypted data channel established based on a point-to-point non-broadcast communication protocol, independent of the Auracast broadcast channel. Its physical layer and data link layer can be implemented based on Wi-Fi or standard Bluetooth pairing connections. The transport layer uses the TCP protocol to ensure connection reliability, and the security layer uses the TLS 1.3 protocol to provide authentication, data encryption, and integrity protection.

[0029] Subsequently, the access control server creates an independent session management thread for the successfully connected target receiving device. This thread calls the system kernel to obtain the current precise time and formats it as a UTC time string, serving as the initial connection timestamp. Simultaneously, based on the device identifier obtained during authentication, the session management thread queries and retrieves the permission level value bound to the device from the permission management database. The permission level is an integer value pre-set in the access control server's access control list, used to distinguish content access permissions or service quality levels for different devices. For example, the value range can be set from 1 to 5, with lower values ​​representing higher permissions; for instance, level 1 corresponds to lossless high-fidelity audio streams, and level 5 corresponds to standard AMR broadband voice streams. Finally, the session management thread stores the initial connection timestamp and permission level together in the device's session state data structure and activates the online status monitoring process, providing a basis for subsequent lifecycle management.

[0030] For example, assume the access control server's IP address is 192.168.1.100 and it listens on TCP port 443. Target receiving device A has a client certificate with device identifier ID-A001. First, target receiving device A initiates a connection to port 443 of 192.168.1.100. Next, the access control server responds and initiates a TLS handshake, sending its server certificate. After verifying the server certificate, target receiving device A sends its client certificate containing its own identifier ID-A001 to the server. Subsequently, the access control server retrieves ID-A001 from its authorized device database, confirms it as a legitimate device, and completes the TLS handshake, establishing an encrypted out-of-band secure control channel. Finally, the server creates a session for this connection, obtains the current system time as the initial connection timestamp, and queries the permission database to find that ID-A001 corresponds to permission level 2. This information is recorded in the session state table maintained for this device in the server's memory, and heartbeat monitoring of the device is initiated.

[0031] In one embodiment of the present invention, the pre-session key distribution module is used to perform the following operations: the access control server uses a cryptographically secure pseudo-random number generator to generate a binary data block that does not have the ability to directly decrypt audio, as a session pre-session key; the session pre-session key and key version identifier are encapsulated and transmitted to the target receiving device through an out-of-band secure control channel; the target receiving device writes the received session pre-session key into a hardware-isolated trusted execution environment or secure element, and sets permission conditions that only allow specific key-derived processes to access it.

[0032] Specifically, after the out-of-band security control channel is established, the session management thread serving the target receiving device in the access control server will execute the session pre-key distribution process. First, the session management thread triggers the key generation module based on the current broadcast session's preset security policy. This module calls a cryptographically secure pseudo-random number generator conforming to the FIPS 140-2 standard to generate a high-entropy data block of a specified bit width; this data block is the session pre-key. Specifically, the session pre-key is a 256-bit static binary data block, its value generated by the cryptographically secure pseudo-random number generator to ensure unpredictability and high entropy. This key is not designed to directly decrypt any audio payload; it serves only as the core seed for subsequent key derivation.

[0033] The access control server encapsulates the generated session pre-key within a data packet, which also includes a single-byte integer as the key version identifier (Key_ID, e.g., 0x01). This packet is then sent to the target receiving device via an established out-of-band secure control channel. Since the out-of-band secure control channel itself is encrypted using the TLS protocol, this transmission process inherently possesses confidentiality and integrity. Upon receiving the data packet, the target receiving device parses and extracts the session pre-key, immediately storing it in its local secure storage area. In this embodiment, the secure storage area refers to a Trusted Execution Environment (TEE) or Secure Element (SE) implemented on the target receiving device hardware, isolated from the main operating system. Examples include a hardware isolation zone based on ARM TrustZone technology or a standalone TPM chip. This area provides hardware-level encryption and access control for the stored data, preventing unauthorized software processes from reading or tampering with it.

[0034] After the storage operation is completed, the application layer logic of the target receiving device will call the interface provided by the operating system to set hardware-level write protection and read-only policies for the storage address where the session pre-key is located. Only pre-defined key derivation functions are allowed to be called through specific APIs, thus locking the read access permission for the session pre-key. Finally, the target receiving device constructs an acknowledgment message containing its own device identifier and a successful reception status code, and sends it back to the access control server via an out-of-band security control channel to confirm the secure reception of the key. This acknowledgment is typically in JSON or XML format, containing a unique ID to identify the device and a status field indicating the processing result, such as {'deviceId':'ID-A001','status':'KEY_RECEIVED_OK'}. Continuing with the previous example, the session management thread of the access control server determines that target receiving device A needs to configure a session key. The server invokes its internal random number generator to generate a 256-bit session pre-concept key, represented in hexadecimal as 0x1A2B3C4D5E6F7890112233445566778899AABBCCDDEEFF00123456789ABCDEF. Next, the server sends this key data to the target receiving device A via the established out-of-band secure control channel. Upon receiving the data, target receiving device A invokes the API provided by its hardware TEE to write the session pre-concept key 0x1A2B3C4D5E6F7890112233445566778899AABBCCDDEEFF00123456789ABCDEF into the TEE's secure memory and sets the access policy to allow only the internal process with the identifier KDF_Handler to access it. Subsequently, target receiving device A constructs a JSON-formatted confirmation receipt with the content '{"deviceId":"ID-A001","status":"SUCCESS"}', and sends it back to the access control server via the out-of-band security control channel. Upon receiving this receipt, the access control server updates the status of target receiving device A to indicate that the key has been synchronized.

[0035] In one embodiment of the present invention, the session key generation module is configured to perform the following steps: the broadcast source device reads the timestamp of the clock or the value of the hardware loop counter, and formats and generates a public synchronization factor that dynamically changes over time; calls a preset key derivation function based on a hash message authentication code; takes the locally stored session precursor key as the key input, takes the public synchronization factor as the message input, performs a one-way hash operation to output a binary data block as the slice session key.

[0036] Specifically, before broadcasting audio data, the broadcast source device first needs to communicate with the access control server to securely obtain and locally store the session pre-key corresponding to this broadcast session through an independent management channel. After entering the real-time broadcast process, the audio processing unit of the broadcast source device divides the continuous audio stream into multiple time slices, each with a length set from 10 ms to 100 ms to adapt to the Bluetooth ISO transmission interval. Before processing the audio data frames contained in each new time slice, the central processing unit of the broadcast source device performs a synchronization factor generation operation. This operation involves calling the system's built-in high-precision clock source, reading the value of a microsecond-level timestamp or hardware loop counter, and using this value as the public synchronization factor. Specifically, the public synchronization factor is a 64-bit non-confidential random number or sequence number, which is forcibly formatted using network byte order when participating in key derivation operations and embedding broadcast packets to ensure data consistency between devices with different architectures. Its main function is to introduce a dynamically changing, publicly known variable into the key derivation process, ensuring that the session key generated for each time slice is unique.

[0037] Subsequently, the broadcast source device calls a key derivation function pre-installed in its firmware, which is a function implementation based on Hash Message Authentication Code (HMAC). The key derivation function takes the locally stored session precursor key as the HMAC key input and the newly generated public synchronization factor as the message input. Finally, the broadcast source device performs a one-way hash operation on the key derivation function, such as an HMAC-SHA256 operation. The output of this operation is a fixed-length binary data block, which is the slice session key specific to the current time slice. It should be understood that this slice session key is a short-lived symmetric encryption key, and its validity is limited to the current time slice. The duration of this time slice is set according to the security requirements of the application scenario, typically between 100 ms and 500 ms.

[0038] The above generation process can be represented by the following formula:

[0039] in, Represents time slice The generated slice session key. This represents the key derivation function, such as the HMAC-SHA256 algorithm. This represents the session pre-key synchronized from the access control server and stored locally on the broadcast source device, which serves as the key for HMAC operations. Represents time slice The publicly available synchronization factor generated at the beginning serves as the message for the HMAC operation. The result of this formula... The length is determined by the chosen hash algorithm; for SHA-256, the output length is 256 bits. Since HMAC is a one-way function, it uses known hash algorithms to... and The inability to derive KP in reverse ensures the security of the session pre-conference key.

[0040] For example, continuing from the previous example, assume that the broadcast source device has obtained the session pre-key 0x1A2B3C4D5E6F7890112233445566778899AABBCCDDEEFF00123456789ABCDEF from the access control server via a secure channel. Before processing the audio frame of the current time slice, the broadcast source device obtains a value from its high-precision clock and generates a 64-bit public synchronization factor, which is represented in hexadecimal as 0xFEDCBA9876543210. Then, the broadcast source device calls a preset key derivation function, namely the HMAC-SHA256 function, to calculate the public synchronization factor using the session pre-key as the key and the public synchronization factor as the message. Finally, the HMAC-SHA256 function outputs a 256-bit hash value, such as 0x9876543210FEDCBA9876543210FEDCBA9876543210FEDCBA9876543210. This value is used as the slice session key for the current time slice, which is used to encrypt the audio data to be broadcast.

[0041] In one embodiment of the present invention, the data encapsulation and transmission module is configured to perform the following steps: encrypt the original audio data using a slice session key and employing the CCM mode of the AES encryption standard to generate an encrypted audio payload and a message authentication code; write the public synchronization factor into the extended broadcast header or manufacturer-specific data field of the broadcast protocol data unit; concatenate the header carrying the public synchronization factor with the encrypted audio payload to generate a composite broadcast data frame, and transmit it through the Bluetooth Low Energy broadcast channel.

[0042] Specifically, after the broadcast source device generates the segment session key, its audio encryption and data encapsulation process is immediately initiated. First, the audio processing subsystem of the broadcast source device passes a segment of raw audio data to be broadcast, such as an audio data frame processed by an LC3 encoder, to the encryption engine. The encryption engine immediately calls the hardware-accelerated AES encryption module and loads the generated segment session key as the symmetric key for the current encryption operation. Simultaneously, it reads the sequence number of the currently transmitted broadcast packet, concatenates or XORs it with the 64-bit public synchronization factor, and fills or maps it into a 96-bit or 104-bit initialization vector (Nonce / IV) according to the requirements of the AES-CCM standard. In this embodiment, the preferred IV construction method is as follows: the 64-bit public synchronization factor is filled into the high 8 bytes of the IV, the 24-bit packet sequence number is filled into the low 3 bytes of the IV, and the remaining middle 1 byte is filled with a fixed value or a counter used to identify the segment. Using AES-CCM mode, the encryption engine encrypts the raw audio data frame and generates authentication tags; its output constitutes the encrypted audio payload. The encrypted audio payload refers to the ciphertext data generated after the original audio data is processed by a symmetric encryption algorithm. In this embodiment, the AES-256-CCM encryption algorithm can be used. This algorithm can generate a message authentication code to ensure the integrity and authenticity of the data while providing data confidentiality.

[0043] In parallel, the protocol stack processing module of the broadcast source device obtains the public synchronization factor and the currently used key version identifier Key_ID, and embeds them as data fields into the extended broadcast header of the standard Auracast broadcast protocol data unit (PDU). Specifically, this operation involves writing the public synchronization factor into a predefined, manufacturer-specific data field whose length matches the synchronization factor's length. This field is unencrypted and can be read by any scanning device. For example, the manufacturer ID might be defined as 0xAAAA, followed by an 8-byte synchronization factor and a 1-byte Key_ID.

[0044] Finally, the protocol stack processing module takes the data packet containing the encrypted audio payload as the main body of the PDU and assembles it with the PDU header, which already carries the public synchronization factor, to form a complete composite broadcast data frame. The composite broadcast data frame follows the Auracast broadcast PDU format defined in the Bluetooth core specification. Specific metadata fields in its extended header are used to carry the public synchronization factor, while its data payload field is filled with the encrypted audio payload. This data frame is then submitted to the physical layer and transmitted outwards via the Bluetooth Low Energy radio unit on a preset broadcast channel. It should be noted that the Bluetooth Low Energy broadcast channel typically refers to the three main broadcast channels defined in the Bluetooth specification for connectionless broadcasting, namely channels 37, 38, and 39; and the isochronous channel for data transmission.

[0045] For example, continuing from the previous example, the broadcast source device now holds the key and synchronization factor. Specifically, the slice session key is 0x9876543210FEDCBA9876543210FEDCBA9876543210FEDCBA9876543210, and the public synchronization factor is 0xFEDCBA9876543210. First, assuming there is a 120-byte LC3-encoded raw audio data frame to be broadcast, the broadcast source device's encryption engine uses the slice session key as the key and employs the AES-256-CCM algorithm to encrypt these 120 bytes of audio data, generating a 120-byte encrypted audio payload. Next, the protocol encapsulation module creates an Auracast broadcast PDU and fills the manufacturer-specific data area in its extended broadcast header with the public synchronization factor 0xFEDCBA9876543210. Subsequently, the aforementioned 120-byte encrypted audio payload is used as the data payload of this PDU. Finally, the composite broadcast data frame, which includes a synchronization factor header and an encrypted payload, is assembled and broadcast on channel 37 via the Bluetooth radio frequency antenna for receiving devices within the coverage area to capture.

[0046] In one embodiment of the present invention, the local key synthesis module is configured to perform the following steps: the target receiving device captures the synthesized broadcast data frame through the broadcast scanning unit and parses the extended broadcast header to separate the public synchronization factor; the session pre-key is retrieved from the secure storage area and a key derivation function consistent with the broadcast source device is loaded; the session pre-key and the extracted public synchronization factor are calculated in real time, and the calculation result is output as the locally synthesized slice session key.

[0047] Specifically, the Bluetooth Low Energy Broadcast Scanning Unit of the target receiving device continuously scans on a preset broadcast channel to capture wireless signals from the broadcast source device. Once the broadcast scanning unit successfully receives a complete synthetic broadcast data frame, the frame is passed to the device's link layer controller for initial processing. Subsequently, the protocol stack parsing module intervenes to perform deep parsing of the extended broadcast header of the synthetic broadcast data frame. This module locates and extracts the public synchronization factor and key version identifier carried within the header, based on a predefined manufacturer-specific data format.

[0048] Simultaneously, the device's application layer logic initiates an API call request to its internal secure storage area. This request aims to retrieve the locally stored session pre-key that matches the extracted key version identifier. After verifying the legitimacy of the call, the secure storage area securely returns the session pre-key to the trusted cryptographic operation module. The cryptographic operation module then calls the same key derivation function as the broadcast source, namely the HMAC-SHA256 algorithm, using the locally called session pre-key as the key input for the HMAC operation and the public synchronization factor just extracted from the broadcast frame as the message input. By executing this one-way hash operation, the target receiving device locally calculates and reconstructs the slice session key that is completely identical to the one currently used by the broadcast source in real time.

[0049] The reduction process can be represented by the following formula:

[0050] in, Represents the target receiving device in the time slice The locally reconstructed slice session key. KDF stands for Key Derivation Function, i.e., the HMAC-SHA256 algorithm. This represents the session pre-key retrieved from the secure storage area of ​​the target receiving device. This represents the public synchronization factor extracted from the received synthetic broadcast data frames. This calculation process ensures that as long as... With the broadcast source Consistent, and If it is the effective synchronization factor of the current broadcast, then the calculated It must be generated at the same time as the broadcast source. Exactly the same.

[0051] Through the above process, the slice session key itself is not transmitted in any channel, but is synthesized in real time at the authorized receiving end through public dynamic parameters and private static parameters, namely synchronization factor and precursor key, thereby realizing secure key distribution and synchronization.

[0052] For example, continuing from the previous example, target receiving device A successfully captures a synthetic broadcast data frame sent by the broadcast source device during its Bluetooth broadcast scan. First, its protocol stack parsing module parses the extended broadcast header of the data frame and successfully extracts the public synchronization factor, which has a value of 0xFEDCBA9876543210. Simultaneously, the device's application logic requests the session pre-conference key from its internal TEE security area. After verifying authorization, the TEE passes the stored key 0x1A2B3C4D5E6F7890112233445566778899AABBCCDDEEFF00123456789ABCDEF to the cryptographic module. Subsequently, this module performs an HMAC-SHA256 operation, using the session pre-conference key as the key and the extracted public synchronization factor as the message. Finally, the output is a 256-bit hash value: 0x9876543210FEDCBA9876543210FEDCBA9876543210FEDCBA9876543210. This value is the locally restored slice session key, which is completely identical to the key generated at the broadcast source and can be immediately used to decrypt the encrypted audio payload in the data frame.

[0053] In one embodiment of the present invention, the audio stream parsing and output module is configured to perform the following steps: load the locally synthesized slice session key into the decryption algorithm module to decrypt the encrypted audio payload in the synthesized broadcast data frame; compare the verification value generated during the decryption process with the message authentication code in the data frame, and if they match, determine that the integrity verification has passed; transmit the decoded audio signal to the audio output unit, and when the next data frame containing a different public synchronization factor is detected, clear the currently used slice session key from memory.

[0054] Specifically, after the target receiving device locally reconstructs the slice session key, this key is immediately used to decrypt the encrypted audio payload in the currently captured synthetic broadcast data frame. The cryptographic module of the target receiving device loads the locally reconstructed slice session key as the key for the AES-CCM decryption algorithm. Subsequently, the encrypted audio payload and the accompanying message authentication code are input into the decryption algorithm.

[0055] After decryption, if the message authentication code verification passes, the algorithm outputs the decrypted original audio data frame. Next, integrity verification is performed. In this embodiment, integrity verification utilizes the built-in message authentication function of AES-CCM mode: during decryption, the algorithm recalculates the message authentication code based on the same key and the decrypted plaintext, and compares it with the received message authentication code; if the two are completely identical, the verification passes.

[0056] If the verification passes, it indicates that the data has not been tampered with during transmission and originates from a legitimate broadcast source. The target receiving device then transmits the decrypted original audio data frame to an audio decoder, such as an LC3 decoder, for decoding to restore it to a Pulse Code Modulation (PCM) audio signal. This PCM audio signal is ultimately sent to the audio output unit for playback. The audio output unit is a hardware combination that receives digital audio signals and converts them into audible sound, typically including a digital-to-analog converter (DAC), a power amplifier, and speaker or headphone drivers.

[0057] At the end of the current broadcast time slice, the termination event is triggered by the target receiving device detecting the next synthesized broadcast data frame containing a different public synchronization factor. It's important to note that the end of the current broadcast time slice is a logical event, not a fixed point in time; it is defined by changes in the public synchronization factor, marking the end of the previous slice's session key's lifecycle. At this point, the device control logic does not immediately physically erase the key but marks it as pending disposal, allowing residual audio frames belonging to the previous time slice in the audio buffer to be decrypted and played. Once the buffer is empty or a preset decryption window period has elapsed, a key discarding operation is performed, completely removing the currently used slice session key from working memory, for example, by overwriting its storage area with zero values. This ensures the key will not be used for subsequent data decryption and prepares the key for synthesizing the next time slice.

[0058] For example, continuing from the previous example, target receiving device A has locally restored the slice session key 0x9876543210FEDCBA9876543210FEDCBA9876543210FEDCBA9876543210. At this point, it extracts 120 bytes of encrypted audio payload and 8 bytes of message authentication code from the synthesized broadcast data frame. First, the target receiving device's AES-CCM decryption engine uses the slice session key to decrypt this 120-byte payload. The decryption process not only restores the 120 bytes of original LC3 audio data but also recalculates the 8-byte message authentication code. Next, this newly calculated authentication code is compared with the original authentication code carried in the data frame, and they are found to be completely identical; therefore, the integrity check passes. Subsequently, this 120 bytes of original LC3 audio data is sent to the LC3 decoder, decoded into a PCM audio stream, and played out through the speaker of the audio output unit. Shortly after, the device received a new broadcast data frame and parsed out a new public synchronization factor of 0x1122334455667788. Because this value is different from the previous one, the device marked the currently used slice session key as expired. After the remaining audio frames in the buffer have finished playing, the old key stored in memory is cleared, and the device prepares to use this new synchronization factor to generate the next key.

[0059] In one embodiment of the present invention, the key lifecycle management module is configured to perform the following operations: the access control server sends a heartbeat detection command to the target receiving device through an out-of-band security control channel and starts a response timeout timer; if no response is received within a preset time limit or a permission revocation command is received, the server sends a key erasure command through the out-of-band security control channel; the target receiving device responds to the key erasure command, or if no confirmation is received from the server when the local security countdown timer expires, it forcibly performs physical overwrite erasure of the locally stored session pre-key.

[0060] Specifically, the session management thread maintains an independent heartbeat timer for each connected target receiving device. When this timer expires, for example, every 10 seconds, the session management thread constructs a heartbeat probe command and sends it to the corresponding target receiving device via an out-of-band security control channel. The heartbeat probe command is typically a small data packet with fixed content, used to confirm link connectivity and the device's online status. After sending, the thread starts an independent response timeout timer, whose time limit is set to a preset limit. This preset time limit is a time window set according to network latency and application scenario reliability requirements, typically between 30 and 90 seconds, to provide sufficient response redundancy.

[0061] If the session management thread successfully receives a valid heartbeat response from the target receiving device within the preset time limit, it resets the heartbeat timer and timeout timer, and the session remains authorized. Simultaneously, the target receiving device resets its local security watchdog timer after each successful heartbeat response and server confirmation. If no response is received by the timeout period, or if the access control server receives a permission revocation command for the device from an external management interface, the thread immediately updates the target receiving device's session state to unauthorized. The unauthorized state is a flag maintained by the server for device sessions; once set, it triggers the subsequent permission revocation process.

[0062] Upon entering an unauthorized state, the session management thread immediately constructs a key erasure command and sends it to the target receiving device via an out-of-band security control channel, forcing its security module to erase the locally stored session pre-key. The key erasure command is a high-priority control command, digitally signed or transmitted via an encrypted channel. Once recognized by the target receiving device's security firmware, this command triggers an irreversible operation, such as multiple overwrites of the physical memory address, to permanently delete the session pre-key from the secure storage area. If the out-of-band security control channel is unavailable at this time, for example, if the device is taken out of network coverage and the key erasure command fails to be sent, the target receiving device's local security watchdog timer will time out due to the lack of server confirmation (e.g., a timeout of 60 seconds). Once timeout occurs, the device firmware will automatically trigger the same security operation as upon receiving the erasure command, forcibly physically erasing the locally stored session pre-key. This ensures that even in a network outage, the offline device's access permissions will automatically expire within a short period. Regardless of the method used, the target receiving device ultimately loses its valid session pre-key, thus preventing it from performing key derivation operations and blocking its ability to synthesize all subsequent slice session keys.

[0063] For example, continuing from the previous example, the access control server maintains a session for target receiving device A, which is playing audio normally. The server's heartbeat detection period is set to 10 seconds, with a preset time limit of 30 seconds. Suppose an administrator issues a permission revocation command for device ID-A001 through the management backend. Upon receiving the command, the access control server immediately changes the session state of target receiving device A from "authorized" to "unauthorized". Subsequently, the server immediately constructs a key erasure command and sends it to target receiving device A using the still-connected out-of-band security control channel. After receiving the command, the application process of target receiving device A forwards it to the internal TEE. After verifying the validity of the command, the TEE performs a secure erasure operation, completely erasing the previously stored session predecessor key 0x1A2B3C4D5E6F7890112233445566778899AABBCCDDEEFF00123456789ABCDEF from its memory. When the next broadcast frame arrives, although device A can still extract the new public synchronization factor, the key derivation function fails during the key synthesis step because a valid session precursor key cannot be obtained, thus failing to generate the correct slice session key. Therefore, the decryption operation also fails, and device A's audio output is interrupted, thereby achieving immediate revocation of permissions.

[0064] Each of the modules can be implemented in whole or in part through software, hardware, or a combination thereof. It supports hardware embedded in or independent of the processor in the computer device, and also supports software stored in the memory of the computer device, so that the processor can call and execute the operations corresponding to each of the above modules.

[0065] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. An Auracast broadcast privacy protection system supporting key distribution and access control, characterized in that, include: The channel establishment and authentication module, the access control server verifies the identity and legitimacy of the target receiving device that initiates the connection, and establishes an out-of-band security control channel independent of the broadcast channel after the verification is passed; The pre-key distribution module generates a static session pre-key through the access control server and encrypts and distributes it to the secure storage area of ​​the target receiving device and to the broadcast source device through an out-of-band secure control channel. The session key generation module generates a public synchronization factor when the broadcast source device processes the current time slice, and combines it with the locally synchronized session precursor key to generate the slice session key using the key derivation function. The data encapsulation and transmission module uses the slice session key to encrypt the audio data and embeds the public synchronization factor into the protocol header, assembling it into a synthetic broadcast data frame before transmission. The local key synthesis module parses the received synthetic broadcast data frame to extract the public synchronization factor and calls the locally stored session pre-key to synthesize the slice session key locally. The audio stream parsing and output module allows the target receiving device to decrypt the encrypted data in the synthesized broadcast data frame using the locally synthesized slice session key and output it for playback. The key is discarded when the current time slice ends. The key lifecycle management module enables the access control server and the target receiving device to perform status monitoring through an out-of-band security control channel, and to perform key erasure operations when the status is determined to be unauthorized or when there is no response after a timeout.

2. The Auracast broadcast privacy protection system supporting key distribution and access control according to claim 1, characterized in that, The channel establishment and authentication module is used to perform the following operations: the access control server responds to the connection request of the target receiving device and initiates a handshake process based on the transport layer security protocol; The access control server and the target receiving device exchange and verify digital certificates to confirm the legitimacy of the device identifier; An end-to-end bidirectional encrypted communication link is established based on the session key negotiated through the handshake, serving as an out-of-band security control channel, and the device's initial connection timestamp and permission level are recorded.

3. The Auracast broadcast privacy protection system supporting key distribution and access control according to claim 1, characterized in that, The pre-session key distribution module is used to perform the following operations: The access control server uses a cryptographically secure pseudo-random number generator to generate a binary data block that does not have the ability to directly decrypt audio, which serves as the session pre-session key; After encapsulating the session pre-session key and key version identifier, it is transmitted to the target receiving device through an out-of-band secure control channel; The target receiving device writes the received session pre-key into a hardware-isolated trusted execution environment or secure element, and sets access permissions that only allow specific key-derived processes to access it.

4. The Auracast broadcast privacy protection system supporting key distribution and access control according to claim 1, characterized in that, The session key generation module performs the following steps: the broadcast source device reads the timestamp of the clock or the value of the hardware loop counter, and formats it to generate a public synchronization factor that changes dynamically over time; it calls a preset key derivation function based on a hash message authentication code; it takes the locally stored session precursor key as the key input, the public synchronization factor as the message input, performs a one-way hash operation, and outputs a binary data block as the slice session key.

5. The Auracast broadcast privacy protection system supporting key distribution and access control according to claim 1, characterized in that, The data encapsulation and transmission module is used to perform the following operations: encrypt the original audio data using the slice session key and the CCM mode of the AES encryption standard to generate an encrypted audio payload and message authentication code; and write the public synchronization factor into the extended broadcast header or manufacturer-specific data field of the broadcast protocol data unit. The header carrying the public synchronization factor is concatenated with the encrypted audio payload to generate a synthetic broadcast data frame, which is then transmitted via the Bluetooth Low Energy Broadcast channel.

6. The Auracast broadcast privacy protection system supporting key distribution and access control according to claim 1, characterized in that, The local key synthesis module is used to perform the following operations: the target receiving device captures the synthesized broadcast data frame through the broadcast scanning unit and parses the extended broadcast header to separate the public synchronization factor; the session pre-key is retrieved from the secure storage area and the key derivation function consistent with the broadcast source device is loaded; The session pre-key and the extracted public synchronization factor are processed in real time, and the result is output as the locally synthesized slice session key.

7. The Auracast broadcast privacy protection system supporting key distribution and access control according to claim 1, characterized in that, The audio stream parsing and output module is used to perform the following operations: load the locally synthesized slice session key into the decryption algorithm module, and decrypt the encrypted audio payload in the synthesized broadcast data frame; The verification value generated during the decryption process is compared with the message authentication code in the data frame. If they match, the integrity verification is deemed successful. The decoded audio signal is transmitted to the audio output unit, and when the next data frame containing a different public synchronization factor is detected, the currently used slice session key is cleared from memory.

8. The Auracast broadcast privacy protection system supporting key distribution and access control according to claim 1, characterized in that, The key lifecycle management module is used to perform the following operations: the access control server sends a heartbeat detection command to the target receiving device through an out-of-band security control channel and starts a response timeout timer; If no response is received within the preset time limit or if a permission revocation instruction is received, the server sends a key erasure instruction through the out-of-band security control channel; The target receiving device responds to the key erasure command, or if no confirmation is received from the server after the local security countdown expires, it forces a physical overwrite and erasure of the locally stored session pre-key.

9. The Auracast broadcast privacy protection system supporting key distribution and access control according to claim 5, characterized in that, The process of generating the encrypted audio payload also includes: reading the packet sequence number of the current audio data frame; combining the public synchronization factor with the packet sequence number; and mapping the combined data to the initial vector field required by the AES-CCM mode.

10. The Auracast broadcast privacy protection system supporting key distribution and access control according to claim 3, characterized in that, After the target receiving device returns a key reception confirmation receipt to the access control server, it calls the operating system interface to set storage permissions for the address of the storage session predecessor key, allowing only trusted applications to access it.

Images