Audio algorithm call management method, audio algorithm call management system and electronic device

Abstract

This application discloses an audio algorithm call management method, an audio algorithm call management system, and an electronic device, comprising: after establishing a communication connection with an audio acquisition device, sending an initial challenge plaintext to the audio acquisition device; after receiving a challenge ciphertext returned by the audio acquisition device, decrypting the challenge ciphertext to obtain a target challenge plaintext; the challenge ciphertext is obtained by the audio acquisition device encrypting the initial challenge plaintext; and controlling the opening and closing state of the audio transmission link between the host and the audio acquisition device, and controlling the calling state of audio algorithm instances, based on the matching result of the target challenge plaintext and the initial challenge plaintext. This prevents unauthorized audio acquisition devices from interacting with the host due to their inability to respond to random initial challenge plaintexts, thereby effectively identifying unauthorized audio acquisition devices and eliminating spoofing and unauthorized calls at the source.

Description

Technical Field

[0001] This application relates to the field of electrical control technology, and more specifically, to an audio algorithm call management method, an audio algorithm call management system, and an electronic device. Background Technology

[0002] Current audio acquisition and processing systems commonly employ a separation architecture between hardware acquisition and host processing. The core algorithm runs on the host side, communicating with the acquisition hardware via Bluetooth. However, this architecture, lacking an effective hardware authentication mechanism, is highly vulnerable to unauthorized hardware spoofing protocols, allowing unauthorized acquisition hardware to access the algorithm's processing capabilities. Summary of the Invention

[0003] In view of the above problems, this application proposes an audio algorithm call management method, an audio algorithm call management system, and an electronic device, which can solve the above problems.

[0004] This invention provides an audio algorithm invocation management method, comprising: after establishing a communication connection with an audio acquisition device, sending an initial challenge plaintext to the audio acquisition device; after receiving a challenge ciphertext returned by the audio acquisition device, decrypting the challenge ciphertext to obtain a target challenge plaintext; wherein the challenge ciphertext is obtained by the audio acquisition device encrypting the initial challenge plaintext; and controlling the opening and closing state of the audio transmission link between the host and the audio acquisition device, and controlling the invocation state of audio algorithm instances, based on the matching result of the target challenge plaintext and the initial challenge plaintext; wherein the audio algorithm instances are used to perform audio processing on the audio data transmitted by the audio acquisition device via the audio transmission link.

[0005] In some implementations, the step of sending an initial challenge plaintext to the audio acquisition device includes: generating an initial challenge plaintext in the event of an authentication triggering event; wherein the authentication triggering event includes detecting that a communication connection with the audio acquisition device has been successfully established, determining that a preset authentication period has arrived, receiving an audio transmission request sent by the audio acquisition device, and receiving a device authentication command input by the user for the audio acquisition device; and sending the initial challenge plaintext to the audio acquisition device.

[0006] In some implementations, the challenge ciphertext is obtained by encrypting the initial challenge plaintext using a preset encryption algorithm and a first preset key by the audio acquisition device; the target challenge plaintext is obtained by decrypting the challenge ciphertext using a preset encryption algorithm and a second preset key by the host; wherein, if the preset encryption algorithm includes a symmetric encryption algorithm, the first preset key and the second preset key are the same shared key, and if the preset encryption algorithm includes an asymmetric encryption algorithm, the first preset key and the second preset key are a paired key pair.

[0007] In some implementations, the second preset key is encapsulated in the host's encryption algorithm encapsulation library. The encryption algorithm encapsulation library is configured to: statically link with the main application during the compilation phase to construct an execution carrier containing the second preset key, and restrict the main application's direct access to the second preset key based on the execution carrier's internal storage mechanism; in response to the main application's key call request, read the second preset key stored internally in the execution carrier, and decrypt the challenge ciphertext according to the preset encryption algorithm and the second preset key to obtain the target challenge plaintext, and return the target challenge plaintext to the main application.

[0008] In some implementations, the steps, based on the matching result of the target challenge plaintext and the initial challenge plaintext, control the opening and closing state of the audio transmission link between the host and the audio acquisition device, and control the calling state of the audio algorithm instance, including: when the target challenge plaintext and the initial challenge plaintext match, allowing the initialization of the audio algorithm instance and the calling of the audio algorithm instance, and configuring the gain parameter of the audio transmission link to a preset output value to enable the audio transmission link; when the target challenge plaintext and the initial challenge plaintext do not match, prohibiting the initialization of the audio algorithm instance and / or the calling of the audio algorithm instance, and setting the gain parameter of the audio transmission link to a mute value to disable the audio transmission link.

[0009] In some implementations, after sending the initial challenge plaintext to the audio acquisition device, the method further includes: determining the sending status of the initial challenge plaintext; and, if the initial challenge plaintext fails to be sent, resending the initial challenge plaintext to the audio acquisition device until the initial challenge plaintext is successfully resent or the cumulative number of resentments reaches a preset threshold.

[0010] In some implementations, before the step of decrypting the ciphertext of the challenge to obtain the target plaintext of the challenge, the method further includes: determining that the ciphertext of the challenge passes the data integrity check.

[0011] In some implementations, in response to a key update command, a first random number is generated; the first random number is encrypted or signed using a second preset key, and the encrypted or signed first random number is sent to the audio acquisition device; when the encrypted or signed second random number is received, an updated second preset key is calculated based on the second preset key, the first random number, and a preset key evolution algorithm; the encrypted or signed second random number is decrypted or verified using the updated second preset key, and if the verification is successful, the local second preset key is updated to the updated second preset key; wherein, the encrypted or signed second random number is generated by the audio acquisition device after verifying the encrypted or signed first random number using the first preset key, calculating the updated first preset key based on the first preset key, the first random number, and a preset key evolution algorithm, and then encrypting or signing the updated first preset key.

[0012] This invention also provides an audio algorithm invocation management system, comprising: a host, configured to send an initial challenge plaintext to an audio acquisition device after establishing a communication connection with the audio acquisition device; an audio acquisition device, configured to encrypt the initial challenge plaintext and send the resulting challenge ciphertext to the host; the host, further configured to decrypt the challenge ciphertext upon receiving it to obtain a target challenge plaintext; and the host, further configured to control the opening and closing state of the audio transmission link between the host and the audio acquisition device, and control the invocation state of audio algorithm instances, based on the matching result between the target challenge plaintext and the initial challenge plaintext; wherein the audio algorithm instance is used to perform audio processing on the audio data transmitted by the audio acquisition device via the audio transmission link.

[0013] This invention also provides an electronic device, including: a processor, a memory, and one or more application programs; the one or more application programs are stored in the memory and configured to be executed by the processor to implement the above-described audio algorithm call management method.

[0014] The technical solution provided in this application includes the following method: after establishing a communication connection with an audio acquisition device, sending an initial challenge plaintext to the audio acquisition device; after receiving a challenge ciphertext returned by the audio acquisition device, decrypting the challenge ciphertext to obtain a target challenge plaintext; wherein the challenge ciphertext is obtained by the audio acquisition device encrypting the initial challenge plaintext; and controlling the opening and closing state of the audio transmission link between the host and the audio acquisition device, and controlling the calling state of the audio algorithm instance, based on the matching result of the target challenge plaintext and the initial challenge plaintext; wherein the audio algorithm instance is used to perform audio processing on the audio data transmitted by the audio acquisition device through the audio transmission link. After establishing a communication connection with the audio acquisition device, the host randomly generates an initial challenge plaintext, receives the ciphertext obtained by encrypting the initial challenge plaintext from the audio acquisition device, and decrypts the ciphertext to obtain the target challenge plaintext. Based on whether the initial challenge plaintext and the target challenge ciphertext match, the host decides whether to call the audio algorithm instance and whether to open the audio transmission link between the host and the audio acquisition device. This prevents unauthorized audio acquisition devices from interacting with the host because they cannot respond to the random initial challenge plaintext, thus effectively identifying unauthorized audio acquisition devices and eliminating spoofing and unauthorized calls at the source. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments and drawings obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0016] Figure 1 A flowchart illustrating an audio algorithm call management method according to an embodiment of this application is shown.

[0017] Figure 2 This paper illustrates a schematic diagram of the structure of an audio algorithm call management system provided in an embodiment of this application.

[0018] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown.

[0019] Figure 4 This illustration shows a schematic diagram of the structure of a computer-readable storage medium provided in an embodiment of this application.

[0020] Figure 5 A schematic diagram of the structure of a computer program product provided in an embodiment of this application is shown. Detailed Implementation

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0023] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0024] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0025] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0027] Please see Figure 1 , Figure 1 This illustration shows a flowchart of an audio algorithm call management method according to an embodiment of this application. It can be applied to a host computer configured with audio algorithm instances, such as... Figure 1 As shown, the method may include steps 110 to 130.

[0028] In step 110, after establishing a communication connection with the audio acquisition device, an initial challenge plaintext is sent to the audio acquisition device.

[0029] The audio acquisition device can be a smart audio peripheral with a built-in microcontroller. In one specific implementation, the audio acquisition device can be a smart microphone array, a USB sound card, an audio dongle with an MCU, or a Bluetooth headset, etc.

[0030] The initial challenge plaintext can be a unique identifier or a random number generated by the host to verify the identity of the audio acquisition device. After establishing a communication connection with the audio acquisition device, the host generates the initial challenge plaintext through its internal random number generator to ensure that the initial challenge plaintext generated each time a communication connection is established is different, thereby preventing malware from using historical authentication data for replay attacks.

[0031] In one specific implementation, the initial challenge plaintext can be a random number, a timestamp, or a specific instruction code.

[0032] Furthermore, in some implementations, the step of sending an initial challenge plaintext to the audio acquisition device may include the following steps: (1) In the event of an authentication triggering event, generate an initial challenge plaintext; wherein, the authentication triggering event includes any one or more of the following: detecting that a communication connection with the audio acquisition device has been successfully established, determining that a preset authentication period has arrived, receiving an audio transmission request sent by the audio acquisition device, and receiving a device authentication command input by the user for the audio acquisition device; (2) Send an initial challenge plaintext to the audio acquisition device.

[0033] In some implementations, the host is configured to, upon receiving a device access signal, determine that a communication connection has been successfully established with the audio acquisition device, and generate and send an initial challenge plaintext.

[0034] In one specific implementation, the device access signal can be emitted by the audio acquisition device when a physical connection or communication link is established between the audio acquisition device and the host, or generated by the host's communication interface / operating system. The device access signal allows the host to perceive the presence of external hardware, thereby automatically triggering the authentication process without requiring cumbersome manual operation by the user.

[0035] For example, when a user plugs an audio acquisition device into the host's USB port, the MCU inside the audio acquisition device sends an enumeration request or connection request via the USB data cable. The host's USB controller detects a level change or receives a USB descriptor sent by the audio acquisition device. The host's operating system encapsulates this hardware event as a device access signal and broadcasts it to the host running at the application layer. After receiving the device access signal, the host can determine that a communication connection has been successfully established with the audio acquisition device. At this point, it immediately generates and sends an initial challenge plaintext to begin authentication.

[0036] For example, when the audio acquisition device completes Bluetooth pairing and establishes a connection with the host, the audio acquisition device sends a connection confirmation packet or a service discovery protocol request to the host. After receiving the connection confirmation packet or service discovery protocol request and establishing a link layer connection, the host's Bluetooth protocol stack sends a connection state change callback to the upper-layer application. This callback event is regarded as a device access signal. The host listens for the device access signal, and once it captures it, it immediately generates and sends an initial challenge plaintext to begin authentication.

[0037] In some implementations, the device access signal not only includes an indication that the connection has been established, but may also carry basic attribute information of the audio acquisition device. For example, when sending the device access signal, the audio acquisition device may include its device type identifier, vendor ID, or protocol version number. After receiving the device access signal, the host can first determine whether the audio acquisition device needs authentication based on this information. If authentication is required, an initial challenge plaintext is generated; if authentication is not required, the device access signal is ignored.

[0038] In other implementations, the host is configured to generate an initial challenge plaintext every preset authentication period. The preset authentication period can be a time span between two preset authentication operations by the host. For example, the preset authentication period can be 30 seconds, 31 seconds, 1 minute, 2 minutes, 1 hour, 4 hours, etc.

[0039] Unlike one-time authentication that only occurs when an audio acquisition device is connected, periodic authentication ensures that the audio acquisition device remains legally authorized throughout the entire lifecycle of audio acquisition.

[0040] In other implementations, the host is configured to receive an audio transmission request from the audio acquisition device, generate and send an initial challenge plaintext. The audio transmission request may be a signal indicating that a Bluetooth link connection has been established between the audio acquisition device and the host.

[0041] For example, when the host detects that a BLE or SPP link with the audio acquisition device has been successfully established, it is considered to have received an audio transmission request initiated by the audio acquisition device. The host then triggers the authentication process, generates and sends an initial challenge plaintext.

[0042] In other implementations, the host is configured to generate and send an initial challenge plaintext in response to a device authentication command input by a user for the audio acquisition device. This device authentication command can be a control signal actively sent by the user to the host through the host's human-machine interface, used to request the establishment or restoration of a trust relationship between the audio acquisition devices.

[0043] For example, when an audio acquisition device is connected but in an unauthenticated or failed authentication state, a virtual button for authorization or re-authentication will be displayed on the host's human-machine interface. When the user clicks the virtual button via a touchscreen or mouse, the host's operating system generates a click event, and the host responds to the click event by generating a device authentication command.

[0044] In one specific implementation, after detecting an authentication trigger event, the host calls a cryptographically secure random number generation function provided by its runtime environment to generate a 16-byte random byte stream, which is then defined as the initial challenge plaintext. The cryptographically secure random number generation function can be either SecureRandom or RAND_bytes.

[0045] In some implementations, the host is also configured to send an initial challenge plaintext via a wireless communication interface, which can be a communication module and protocol stack for contactless data exchange between the host and the audio acquisition device. The wireless communication interface can be implemented based on Bluetooth Low Energy, Wi-Fi, ZigBee, or a proprietary 2.4GHz wireless protocol.

[0046] The use of a wireless communication interface to transmit the initial challenge plaintext eliminates the need for the audio acquisition device to be connected to the host via a physical cable, thus improving the deployment flexibility and user portability of this application.

[0047] In one specific implementation, the wireless communication interface can be the host's Bluetooth module and the Bluetooth radio frequency unit integrated into the audio acquisition device. The host calls the Bluetooth API to write the initial challenge plaintext into a specific characteristic value exposed by the audio acquisition device, or sends it through a notification or indication channel in the general attribute profile. The audio acquisition device listens for the write event of this characteristic value through its internal general attribute profile server. When the audio acquisition device detects a change in the characteristic value, i.e., receives the initial challenge plaintext, it triggers an interrupt service routine, reads the data in the Bluetooth receive buffer, and passes it as an input parameter to the encryption algorithm module to perform encryption processing, which will be described in detail later.

[0048] In one specific implementation, the wireless communication interface can be a Wi-Fi interface based on the TCP / IP protocol stack. The host acts as a TCP client, establishing a Socket connection and sending the initial challenge plaintext as a binary stream or JSON format data packet to the fixed IP address and port number of the audio acquisition device. After receiving the network data packet, the MCU of the audio acquisition device parses the packet header and extracts the initial challenge plaintext from the payload, and then performs encryption processing.

[0049] Due to the instability of wireless channels, in some implementations, when sending the initial challenge plaintext via the wireless communication interface, the host can also start a response timeout timer. If the encrypted data returned by the audio acquisition device is not received via the wireless interface within the specified time, the host can automatically retransmit the initial challenge plaintext or prompt the user to check the device's battery level and signal strength.

[0050] In some implementations, after sending the initial challenge plaintext to the audio acquisition device, the audio algorithm invocation management method may further include the following steps: (1) Determine the sending status of the initial challenge plaintext; (2) If the initial challenge plaintext fails to be sent, resend the initial challenge plaintext to the audio acquisition device until the initial challenge plaintext is successfully resent or the cumulative number of resends reaches the preset threshold.

[0051] After the host sends the initial challenge plaintext to the Bluetooth protocol stack for transmission, a timer of preset duration is started. The host determines the transmission status of the initial challenge plaintext by listening to the callback interface of the Bluetooth protocol stack or reading the status register of the underlying driver.

[0052] For example, if the host receives an acknowledgment signal from the audio acquisition device within a preset time period, such as a Write Response in the BLE protocol or an ACK in the SPP protocol, or receives a successful transmission event reported by the protocol stack, then the transmission status is determined to be successful and the timer is stopped.

[0053] If the host does not receive an acknowledgment signal within the preset time and the timer times out, or receives an abnormal status such as transmission failure, connection loss, or busy reported by the protocol stack, the transmission status is determined to be failed. In response to the transmission failure, the host increments the retransmission counter by 1 and checks whether the current number of retransmissions is less than a preset threshold, such as 3 or 5 times. The specific value can be set according to stability requirements. If the threshold is not reached, the host reconstructs a data packet containing the original initial challenge plaintext and retransmits it to the audio acquisition device via the Bluetooth link. If the threshold is reached, the authentication process is determined to have completely failed, subsequent authentication operations are terminated, and the user is prompted to check the device connection status.

[0054] In addition, to prevent wireless over-the-air eavesdropping, the initial challenge plaintext can be encrypted by a transport layer before being transmitted through the wireless interface, ensuring that the initial challenge plaintext itself is not eavesdropped during over-the-air transmission, further enhancing the security of the authentication process.

[0055] In step 120, after receiving the challenge ciphertext returned by the audio acquisition device, the challenge ciphertext is decrypted to obtain the target challenge plaintext.

[0056] The challenge ciphertext is obtained by encrypting the initial challenge plaintext using the audio acquisition device.

[0057] In some implementations, the challenge ciphertext is obtained by encrypting the initial challenge plaintext using a preset encryption algorithm and a first preset key. It should be noted that the first preset key is a key held by the audio acquisition device.

[0058] The challenge ciphertext can be data generated by the audio acquisition device after encrypting or signing the initial challenge plaintext using a first preset key. Due to the one-way nature or security of the preset encryption algorithm, even if the challenge ciphertext is intercepted by a third party during transmission, the first preset key cannot be deduced. Essentially, the challenge ciphertext is used by the audio acquisition device to prove to the host that it possesses legitimate authorization.

[0059] In some implementations, before the step of decrypting the ciphertext of the challenge to obtain the target plaintext of the challenge, the audio algorithm invoking management method may further include: determining that the ciphertext of the challenge passes the data integrity check.

[0060] After receiving the encrypted data from the audio acquisition device, the host first performs a data integrity check, which includes at least a check on the data length of the challenge ciphertext and / or a check on the preset format.

[0061] In one specific implementation, since the AES-128 encryption algorithm is used, the valid ciphertext length should be strictly equal to 16 bytes. Therefore, the host first determines whether the length of the received data is 16 bytes; if the length of the received data is not 16 bytes, the data integrity check is directly deemed to have failed. In addition, the host can also check whether the data packet header or specific flag bits conform to the preset communication protocol format.

[0062] The host will only perform subsequent decryption operations if the challenge ciphertext passes the above data integrity verification; if the verification fails, the authentication will be directly determined to have failed, and an exception handling mechanism will be triggered, such as discarding the data packet and waiting for retransmission or directly disconnecting the connection.

[0063] By adding a data integrity verification step before decryption, garbled data caused by transmission interference or illegally forged short or long packets can be effectively filtered out, improving security and processing efficiency.

[0064] In some implementations, the target challenge plaintext is obtained by the host decrypting the challenge ciphertext using a preset encryption algorithm and a second preset key. The target challenge plaintext can also be data restored by the host after decrypting or verifying the received challenge ciphertext using the second preset key.

[0065] It should be noted that the second preset key is the key held by the host.

[0066] A preset encryption algorithm is a pre-agreed data encryption and decryption rule between the host and the audio acquisition device. In some implementations, the preset encryption algorithm can be a symmetric encryption algorithm, such as AES, DES, or 3DES. In other implementations, the preset encryption algorithm can be an asymmetric encryption algorithm, such as RSA or ECC. In still other implementations, the preset encryption algorithm can be an elliptic curve signature algorithm. For ease of description, this application uses the AES-128 algorithm as an example for detailed description.

[0067] It is worth noting that the host and audio acquisition device must support the same or compatible algorithm logic to ensure the normal operation of data encryption and decryption.

[0068] The first preset key can be stored in the secure storage area of ​​the audio acquisition device and cannot be read externally. For example, the first preset key can be stored in an eFuse or a security chip. The second preset key is stored in the encryption algorithm encapsulation library of the host 210.

[0069] The first preset key and the second preset key are mathematically related. Specifically, in some embodiments, if the preset encryption algorithm includes a symmetric encryption algorithm, then the first preset key and the second preset key are the same shared key; if the preset encryption algorithm includes an asymmetric encryption algorithm, then the first preset key and the second preset key are a paired key pair.

[0070] In some implementations, the second preset key is encapsulated in the host's encryption algorithm encapsulation library; the encryption algorithm encapsulation library is configured as follows: (1) During the compilation stage, static linking is performed with the main application to construct an execution carrier containing the second preset key, and the main application's direct access to the second preset key is restricted based on the internal storage mechanism of the execution carrier; (2) In response to the key call request of the main application, read the second preset key stored in the execution carrier, and decrypt the challenge ciphertext according to the preset encryption algorithm and the second preset key to obtain the target challenge plaintext, and return the target challenge plaintext to the main application.

[0071] During the compilation phase, the encryption algorithm encapsulation library is statically linked with the main application to construct an execution vector containing the second preset key, i.e., the final APP installation package or executable file. During the linking process, the second preset key is stored in a private data segment inside the execution vector, and corresponding memory access permissions, such as read-only attributes, are set through compiler instructions or linker scripts. This restricts other modules of the main application from direct plaintext access to the second preset key based on the execution vector's internal storage mechanism.

[0072] During runtime, when the main application needs to perform authentication verification, it does not directly manipulate the key. Instead, it sends a key call request to the encryption algorithm encapsulation library. In response to the request, the encryption algorithm encapsulation library reads the second preset key stored inside the execution carrier, uses the preset decryption algorithm to decrypt the challenge ciphertext, obtains the target challenge plaintext, and only returns the decryption result to the main application, i.e., verification passed / failed or plaintext data, without exposing the second preset key itself to the outside.

[0073] In step 130, based on the matching result between the target challenge plaintext and the initial challenge plaintext, the system controls the opening and closing status of the audio transmission link between the host and the audio acquisition device, as well as the calling status of the audio algorithm instance.

[0074] Among them, the audio algorithm example is used to process audio data transmitted by the audio acquisition device through the audio transmission link.

[0075] Specifically, in some implementations, the steps of controlling the opening and closing state of the audio transmission link between the host and the audio acquisition device, and controlling the calling state of the audio algorithm instance, based on the matching result of the target challenge plaintext and the initial challenge plaintext, may include the following steps: (1) If the target challenge plaintext matches the initial challenge plaintext, the audio algorithm instance can be initialized and the audio algorithm instance can be invoked, and the gain parameter of the audio transmission link can be configured to a preset output value to enable the audio transmission link. (2) If the target challenge plaintext does not match the initial challenge plaintext, the initialization of the audio algorithm instance and / or the invocation of the audio algorithm instance shall be prohibited, and the gain parameter of the audio transmission link shall be set to the mute value to shut down the audio transmission link.

[0076] After receiving the target challenge plaintext, the host matches it with the previously generated initial challenge plaintext. If the match result is consistent between the target challenge plaintext and the initial challenge plaintext, the host is considered to have correctly decrypted the challenge ciphertext using the second preset key, and the first preset key held by the currently connected audio acquisition device is correct. The audio acquisition device is authorized by the host, and at this time, both algorithm-level processing permissions and signal-level audio transmission links are enabled for the audio acquisition device. This ensures that unauthorized audio acquisition devices cannot utilize the host's audio algorithm resources, nor can they output sound to the host.

[0077] In practical applications, if the host determines that the target challenge plaintext matches the initial challenge plaintext, it allows the initialization and invocation of the audio algorithm instance, as well as the configuration of the gain parameters of the audio transmission link to preset output values.

[0078] The host can call a preset algorithm initialization function. This function uses the target challenge plaintext and the initial challenge plaintext exchanged during authentication as parameters to create and initialize a running instance of the audio algorithm. Only after successfully creating this instance will the host be allowed to respond to audio processing requests, thereby calling the audio algorithm instance and running audio processing functions, such as the `focusme_process` function. In one specific implementation, the audio algorithm instance is activated and can perform processing operations such as noise reduction, echo cancellation, or beamforming on the acquired raw audio data.

[0079] The preset output value can be a value that allows audio signals to pass through normally. The preset output value represents the open or normal working state of the audio transmission link.

[0080] Specifically, the host prohibits the initialization of audio algorithm instances and / or the invocation of audio algorithm instances, and sets the gain parameter of the audio transmission link to a mute value to shut down the audio transmission link.

[0081] If the matching result shows that the target challenge plaintext does not match the initial challenge plaintext, it is considered that the host cannot correctly decrypt the challenge ciphertext using the second preset key, the first preset key held by the currently connected audio acquisition device is incorrect, the audio acquisition device is not authorized by the host, and the audio acquisition device may be an illegal device, a counterfeit device, or a device whose authorization has expired. At this time, the host cuts off access to audio algorithm resources at the software interface level to prevent illegal hardware from stealing or using the host's audio processing capabilities, and also prohibits the opening of the audio transmission link at the signal layer.

[0082] In practical applications, if the host determines that the target challenge plaintext does not match the initial challenge plaintext, it can prevent the initialization of the audio algorithm instance, prevent the calling of the audio algorithm instance when the audio algorithm instance has been initialized, or directly prevent the initialization and calling of the audio algorithm instance at the same time, and configure the gain parameter of the audio transmission link to a mute value to cut off the audio transmission link.

[0083] The host can prevent the call to the preset algorithm initialization function, or the preset algorithm initialization function can force the return of an error code or null reference when it detects an abnormal authentication status, so that the audio algorithm instance cannot be created, the memory resources required by it will not be allocated, and the context environment cannot be established.

[0084] The mute value can be a gain parameter value that attenuates the amplitude of an audio signal to an imperceptible level or even zero. It's important to note that cutting off the audio transmission link does not mean physically disconnecting the connection, but rather using software control to force the gain parameter of the audio transmission link to a mute value, causing the audio signal to be completely blocked or attenuated to zero during transmission, thus preventing it from being played through the speakers.

[0085] In some implementations, the audio algorithm invoking the management method may further include the following steps: (1) In response to the key update instruction, generate a first random number; (2) Encrypt or sign the first random number using the second preset key, and send the encrypted or signed first random number to the audio acquisition device; (3) When the second random number after encryption or signature is received, the updated second preset key is calculated according to the second preset key, the first random number and the preset key evolution algorithm; (4) Decrypt or verify the encrypted or signed second random number according to the updated second preset key, and if the verification is successful, update the local second preset key to the updated second preset key.

[0086] The second random number, after encryption or signing, is generated by the audio acquisition device based on the first preset key, after the first random number is encrypted or signed and verified, and then calculated according to the first preset key, the first random number, and the preset key evolution algorithm to obtain the updated first preset key, and then encrypting or signing the updated first preset key.

[0087] The first random number is generated by the host and serves as the credential for the host to send an update request to the audio acquisition device. This ensures that the key update request is real-time and prevents attackers from deceiving the audio acquisition device by replaying old update commands.

[0088] The second random number, after encryption or signing, is generated by the audio acquisition device and serves as an update confirmation credential returned by the audio acquisition device to the host. This credential checks whether the audio acquisition device has successfully calculated the new key and also challenges whether the audio acquisition device has synchronously calculated the correct new key.

[0089] The preset key evolution algorithm can be a pre-agreed and consistent computational logic between the host and the audio acquisition device, such as one based on the key derivation function (KDF). The core logic of the preset key evolution algorithm is that since both communicating parties possess the same old key and have obtained the same first random number through interaction, each party can independently run the algorithm locally and will inevitably be able to calculate the exact same new key. This ensures that the new key is never transmitted over the network but is calculated locally by both parties, greatly reducing the risk of key leakage.

[0090] When the host detects a key update command, it uses the second preset key currently stored locally, i.e. the old key, to encrypt or digitally sign the first random number to prove to the audio acquisition device that the host is a device with a legitimate old key, and requests a key update to obtain the updated second preset key.

[0091] After receiving the encrypted or signed first random number, the audio acquisition device uses its locally stored first preset key (i.e., the old key paired with the host's second preset key) to decrypt or verify the signature. Successful verification means the audio acquisition device has successfully reconstructed the first random number. If verification fails, for example, due to a key mismatch, it indicates an invalid request, and the process terminates.

[0092] After successful verification and obtaining the first random number, the audio acquisition device does not directly use the first preset key. Instead, it uses a preset key evolution algorithm, combining the first preset key and the first random number as input parameters, to independently calculate and generate an updated first preset key locally—the new key. To confirm that the host can also update synchronously, the audio acquisition device generates a second random number and encrypts or signs it using the calculated updated first preset key, sending it back to the host to inform it that the hardware has been updated and to use the new key for decryption.

[0093] After receiving encrypted or signed data from the hardware, the host executes the synchronization logic. Since the host knows the old key, i.e., the second preset key, and the first random number it issued, and the preset key evolution algorithm is consistent with that of the audio acquisition device, the host can calculate the updated second preset key locally using the same algorithm and parameters.

[0094] At this point, theoretically, the host's new key and the audio acquisition device's new key should be completely identical. The host uses the newly calculated updated second preset key to attempt to decrypt or verify the data sent by the audio acquisition device. If the verification is successful, i.e., the second random number is successfully recovered, it proves that the audio acquisition device has indeed completed the key update, and the new keys calculated by both parties match. After successful dual verification, the host officially switches its local key state to the updated second preset key, completing the entire update process.

[0095] Please see Figure 2 , Figure 2 This paper illustrates a schematic diagram of the structure of an audio algorithm call management system provided in an embodiment of this application, as shown below. Figure 2 As shown, the audio algorithm call management system 200 includes: a host 210 and an audio acquisition device 220, specifically: The host 210 is used to send an initial challenge plaintext to the audio acquisition device 220 after establishing a communication connection with the audio acquisition device 220; The audio acquisition device 220 is used to encrypt the initial challenge plaintext and send the obtained challenge ciphertext to the host 210. The host 210 is also used to decrypt the challenge ciphertext after receiving it to obtain the target challenge plaintext. The host 210 is also used to control the opening and closing state of the audio transmission link between the host 210 and the audio acquisition device 220, and to control the calling state of the audio algorithm instance, based on the matching result of the target challenge plaintext and the initial challenge plaintext; wherein, the audio algorithm instance is used to perform audio processing on the audio data transmitted by the audio acquisition device 220 through the audio transmission link.

[0096] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0097] In the several embodiments provided in this application, the coupling or direct coupling or communication connection between the modules shown or discussed may be an indirect coupling or communication connection through some interface, device or module, and may be electrical, mechanical or other forms.

[0098] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0099] Please see Figure 3 , Figure 3 The diagram illustrates the structure of an electronic device according to an embodiment of this application. The electronic device 300 in this application may include one or more of the following components: a processor 310, a memory 320, and one or more application programs. The one or more application programs may be stored in the memory 320 and configured to be executed by one or more processors 310. The one or more programs are configured to execute the audio algorithm call management method as described in the foregoing method embodiments.

[0100] Processor 310 may include one or more processing cores. Processor 310 connects to various parts within the electronic device 300 using various interfaces and lines, and performs various functions and processes data of the electronic device 300 by running or executing instructions, programs, code sets, or instruction sets stored in memory 320, and by calling data stored in memory 320. Optionally, processor 310 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 310 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 310 and may be implemented separately using a communication chip.

[0101] The memory 320 may include random access memory (RAM) or read-only memory (ROM). The memory 320 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 320 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described below, etc. The data storage area may also store data created by the electronic device 300 during use.

[0102] Please see Figure 4 , Figure 4 This illustration shows a schematic diagram of a computer-readable storage medium 400 provided in an embodiment of this application. The computer-readable storage medium 400 stores program code, which can be called by a processor to execute the audio algorithm call management method described in the above method embodiment.

[0103] The computer-readable storage medium 400 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 400 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 400 has storage space for program code 410 that performs any of the method steps described above. This program code can be read from or written to one or more computer program devices. The program code 410 may be compressed, for example, in a suitable form.

[0104] Please see Figure 5 , Figure 5 The diagram illustrates the structure of a computer program product according to an embodiment of this application. The computer program product 500 includes a computer program 510 stored on a computer-readable storage medium. The computer program 510 includes program instructions, which, when executed by a computer, cause the computer to execute the aforementioned audio algorithm call management method.

[0105] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 this application.

Claims

1. An audio algorithm call management method, characterized in that, Applied to a host computer configured with an audio algorithm instance; the method includes: After establishing a communication connection with the audio acquisition device, an initial challenge plaintext is sent to the audio acquisition device; After receiving the challenge ciphertext returned by the audio acquisition device, the challenge ciphertext is decrypted to obtain the target challenge plaintext; wherein, the challenge ciphertext is obtained by the audio acquisition device encrypting the initial challenge plaintext; Based on the matching result between the target challenge plaintext and the initial challenge plaintext, the system controls the opening and closing state of the audio transmission link between the host and the audio acquisition device, as well as the calling state of the audio algorithm instance; wherein, the audio algorithm instance is used to perform audio processing on the audio data transmitted by the audio acquisition device through the audio transmission link.

2. The audio algorithm call management method according to claim 1, characterized in that, The step of sending an initial challenge plaintext to the audio acquisition device includes: In the event of an authentication triggering event, the initial challenge plaintext is generated; wherein, the authentication triggering event includes any one or more of the following: detecting that a communication connection has been successfully established with the audio acquisition device, determining that a preset authentication period has arrived, receiving an audio transmission request sent by the audio acquisition device, and receiving a device authentication command input by the user for the audio acquisition device; Send the initial challenge plaintext to the audio acquisition device.

3. The audio algorithm call management method according to claim 1, characterized in that, The challenge ciphertext is obtained by the audio acquisition device encrypting the initial challenge plaintext according to a preset encryption algorithm and a first preset key; The target challenge plaintext is obtained by the host decrypting the challenge ciphertext according to the preset encryption algorithm and the second preset key; Wherein, if the preset encryption algorithm includes a symmetric encryption algorithm, then the first preset key and the second preset key are the same shared key; if the preset encryption algorithm includes an asymmetric encryption algorithm, then the first preset key and the second preset key are a paired key pair.

4. The audio algorithm call management method according to claim 3, characterized in that, The second preset key is encapsulated in the encryption algorithm encapsulation library of the host; the encryption algorithm encapsulation library is configured as follows: During the compilation phase, static linking is performed with the main application to construct an execution carrier containing the second preset key, and based on the internal storage mechanism of the execution carrier, direct access of the main application to the second preset key is restricted; In response to the key call request of the main application, the second preset key stored inside the execution carrier is read, and the challenge ciphertext is decrypted according to the preset encryption algorithm and the second preset key to obtain the target challenge plaintext, and the target challenge plaintext is returned to the main application.

5. The audio algorithm call management method according to claim 1, characterized in that, The steps, based on the matching result between the target challenge plaintext and the initial challenge plaintext, control the opening and closing state of the audio transmission link between the host and the audio acquisition device, and control the invocation state of the audio algorithm instance, including: If the target challenge plaintext matches the initial challenge plaintext, the audio algorithm instance is initialized and invoked, and the gain parameter of the audio transmission link is configured to a preset output value to enable the audio transmission link. If the target challenge plaintext does not match the initial challenge plaintext, the initialization of the audio algorithm instance and / or invocation of the audio algorithm instance is prohibited, and the gain parameter of the audio transmission link is set to a mute value to shut down the audio transmission link.

6. The audio algorithm call management method according to claim 1, characterized in that, After sending the initial challenge plaintext to the audio acquisition device, the method further includes: Determine the transmission status of the initial challenge plaintext; If the initial challenge plaintext fails to be sent, the initial challenge plaintext is resent to the audio acquisition device until the initial challenge plaintext is successfully resent or the cumulative number of resentments reaches a preset threshold.

7. The audio algorithm call management method according to claim 1, characterized in that, Before the step of decrypting the ciphertext of the challenge to obtain the plaintext of the target challenge, the method further includes: The challenge ciphertext was confirmed to have passed the data integrity check.

8. The audio algorithm invocation management method of any of claims 1 to 7, wherein, The method further includes: In response to the key update command, generate a first random number; The first random number is encrypted or signed using a second preset key, and the encrypted or signed first random number is sent to the audio acquisition device. When the second random number after encryption or signature is received, the updated second preset key is calculated based on the second preset key, the first random number, and the preset key evolution algorithm. The encrypted or signed second random number is decrypted or verified according to the updated second preset key, and if the verification is successful, the local second preset key is updated to the updated second preset key. The second random number after encryption or signing is generated by the audio acquisition device after verifying the first random number after encryption or signing according to the first preset key, calculating the updated first preset key based on the first preset key, the first random number and the preset key evolution algorithm, and encrypting or signing the updated first preset key.

9. An audio algorithm invocation management system, characterized by Includes the host computer and audio acquisition equipment; The host is used to send an initial challenge plaintext to the audio acquisition device after establishing a communication connection with the audio acquisition device; The audio acquisition device is used to encrypt the initial challenge plaintext and send the obtained challenge ciphertext to the host. The host is also configured to decrypt the challenge ciphertext after receiving it to obtain the target challenge plaintext. The host is further configured to control the opening and closing state of the audio transmission link between the host and the audio acquisition device, and to control the calling state of the audio algorithm instance, based on the matching result of the target challenge plaintext and the initial challenge plaintext; wherein the audio algorithm instance is used to perform audio processing on the audio data transmitted by the audio acquisition device through the audio transmission link.

10. An electronic device, comprising: include: One or more processors; Memory; one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications configured to perform the audio algorithm invocation management method of any one of claims 1-8.

Images