End-to-end protection method and system for call recording digital watermark

Abstract

The invention discloses an end-to-end protection method and system for a call recording digital watermark. The telephone platform completes sub-microsecond-level zero-copy disk falling through the zero-kernel heterogeneous acceleration channel only at the moment when a call is ended and a BYE signaling arrives, and synchronously generates a far-end disaster recovery copy; then, a one-time encrypted watermark is asked from a watermark platform by using a single packet TLS 1.3-RTT Exsion less than or equal to 64B, and no key information is cached locally; the watermark platform instantaneously generates a global unique ciphertext watermark based on a call identity, a timestamp and a hardware true random number, and stores a key in an HSM volatile slot to form a verifiable index; and the telephone platform completes watermark embedding locally by using an echo parameter space which is imperceptible to human ears, and uploads the recording with the watermark to a file for storage through NVMe-oF. The system adopts a three-power discrete architecture, records, watermarks and indexes are separately stored, complete information cannot be recovered through single-point break, and the high-concurrency, low-delay and strong-consistency security compliance requirements are met.

Description

Technical Field

[0001] This invention relates to the field of voice communication and information security technology, and in particular to an end-to-end protection method and system for digital watermarking of call recordings. Background Technology

[0002] Current telephone recording systems generally use the following two modes of disk recording and watermark addition:

[0003] Centralized processing on the platform: After the audio files are uploaded to the central server, watermarks are embedded, which has problems such as high network latency, high platform computing power consumption, and high risk of data leakage.

[0004] Local offline processing: Watermarked files are pre-installed on the terminal, which is not updated in a timely manner, is easily reverse-analyzed or tampered with, and cannot form a rigid identity mapping.

[0005] In addition, traditional disk copying requires multiple user-space to kernel-space copies, and sudden I / O at the moment the call ends can easily lead to packet loss or delay, which cannot meet the requirements of high concurrency, low latency, and strong consistency scenarios. Summary of the Invention

[0006] The purpose of this invention is to provide an end-to-end protection method and system for digital watermarking of call recordings, thereby solving the aforementioned problems existing in the prior art.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0008] A method for adding watermarks to call recordings based on a telephone platform includes the following steps:

[0009] S1. Signaling-triggered heterogeneous acceleration disk recording: The telephone platform only starts the "zero kernel participation" heterogeneous acceleration channel at the moment the BYE signaling for the end of the call arrives. It uses a single atomic instruction to persist the voice data scattered in the user space buffer as the local original recording with zero copying, and simultaneously generates a disaster recovery copy for the peer end, eliminating disk recording delay and packet loss risk in one go.

[0010] S2, Minimal Watermark Request: After the disk is written, the telephone platform immediately requests a one-time encrypted digital watermark from the watermark platform with a single minimal message, and does not cache any watermark information locally;

[0011] S3. Instantly generate verifiable watermarks: Upon receiving a request, the watermark platform generates a globally unique digital watermark in real time based on the caller's identity, timestamp, and random factor. After encryption, the watermark is fed back to the telephone platform, and a verifiable index is stored.

[0012] S4. Locally Imperceptible Embedding: The telephone platform uses echo parameter space that is imperceptible to the human ear to embed the encrypted watermark into the original recording, forming a watermarked recording which is then uploaded to file storage.

[0013] S5. One-to-one rigid verification: Any subsequent verification party can extract the watermark from the recording simply through the watermarking platform and compare it with the left index to trace back to obtain the original call identity and generation time, realizing an inseparable one-to-one rigid mapping of "recording-identity".

[0014] Preferably, step S1, "signaling-triggered heterogeneous accelerated disk write," includes:

[0015] S11. During the call duration, the telephony platform pre-allocates a large-page circular buffer in user mode, and the kernel bypasses the reception of RTP packets. When the BYE signal arrives, the CPU executes an AVX-512 non-temporary storage instruction to write the buffer metadata into the NVMe-oF user-mode driver queue and simultaneously starts the RDMA engine and DMA engine.

[0016] S12. The FPGA network card enters the hardware pipeline under the same instruction pulse: sequentially executes RTP sequence number continuity check, packet loss interpolation compensation, 16kHz to 8kHz resampling and AES-GCM integrity tag calculation, and outputs PCM data block and its 256-bit MAC.

[0017] S13. The host RDMA controller writes PCM data blocks to the remote persistent memory pool through the NVMe-oF extended command, then generates Reed-Solomon(10,4) redundant chips and writes them back to the local SSD to form a disaster recovery copy for the peer.

[0018] S14. The above operations are completed within a single CPU clock cycle, with a disk write latency of less than 800ns and a CPU utilization rate of less than 0.5%. When the link fails, the FPGA switches to a redundant channel to continue writing.

[0019] Preferably, step S2, "minimizing watermark retrieval," includes:

[0020] S21. After disk writing is completed, the interruption triggers the telephone platform to construct a single packet TLS 1.30-RTT Extension. The payload contains a 16B application ID and a 16B server IP. The overall packet length is ≤64B.

[0021] S22, Extension adds 192-bit hardware true random number and the first 8 bytes of SHA-256 certificate fingerprint;

[0022] S23. The telephony platform sends the extension through the TLS early data channel, and only retains the sending descriptor locally, without caching random numbers, fingerprints and watermark information;

[0023] S24. The watermarking platform queries the instantaneous request table using a random number as the key. If the key exists, it is discarded; otherwise, the random number, application ID, and server IP are written into the table before watermark generation continues.

[0024] Preferably, step S3, "instantly generating a verifiable watermark," includes:

[0025] S31. When the TLS 1.3 handshake is interrupted, the watermarking platform reads the application ID, server IP, 192-bit random number and UTC timestamp from the request packet in the kernel bypass big page memory area and concatenates them to form a plaintext block.

[0026] S32. A hardware true random number generator is used to generate a 256-bit session key, which is then encrypted into a plaintext block using AES-256-GCM to generate a 128-bit authentication tag, together forming the digital watermark ciphertext.

[0027] S33. Concatenate the session key and the authentication tag and write them into the volatile key slot of the platform HSM. Establish a hash mapping between the slot address and the random number to form a verifiable index.

[0028] S34. The watermarking platform encapsulates the ciphertext and random number into a TLS application data record and immediately feeds it back to the telephone platform. The plaintext and session key are not stored locally.

[0029] Preferably, step S4, "locally imperceptible embedding," includes:

[0030] S41. After receiving the digital watermarked ciphertext, the telephone platform divides it into 128-bit blocks, and each block is mapped to a pair of echo delays Δt∈{0.5 ms, 1ms} and amplitudes a∈{−24dB, −30dB}, forming a bit-parameter lookup table;

[0031] S42. In user space, open a double buffer, read the original PCM in 20ms frames, synchronously query the lookup table, and generate the corresponding echo kernel h(t)=α·δ(t−Δt) in real time, and convolve it with the original frame to complete the embedding.

[0032] S43. After the convolution output is saturated by INT16, it is directly written back to the file handle without generating intermediate buffer, thus forming a watermarked recording.

[0033] S44. The telephone platform sends watermarked recordings to file storage via the NVMe-oF PUT object interface. The metadata only contains the object name and length and does not carry echo parameters.

[0034] Preferably, step S5, "one-to-one rigidity verification," includes:

[0035] S51. The verifier uploads the audio file to be inspected to the watermarking platform through the TLS 1.3 two-way authentication channel. The platform immediately creates a read-only memory mapping in user space and extracts the echo kernel h(t) by sliding at 20ms frames.

[0036] S52. Deconvolve each frame using a matched filter to restore the bitstream. After decryption using AES-256-GCM, obtain the quadruple {Application ID, Server IP, Random Number, UTC Timestamp}.

[0037] S53. Using the decrypted random number as the key, query the volatile key slot in the HSM. If the session key in the slot matches the authentication tag and the decryption result, output the quadruple; otherwise, return an empty value.

[0038] S54. The entire verification process is completed only in the platform's memory, without storing the recording or the decrypted plaintext on the ground.

[0039] Preferably, the "signaling-triggered heterogeneous accelerated disk write" in step S1 satisfies the following formula condition:

[0040] Let the call end signaling arrive at time t0, defined as:

[0041] The remaining speech blocks in the loop buffer = ∑(i=0→N-1) frames[i], where frame[i] ∈ user-space big page buffer;

[0042] CPU executes a single vector non-temporal write instruction:

[0043] PCM0(t0) = Vector Stream Memory (Ring Buffer Address, Reordering Messages (Δt≤20μs)⊕RS(10,4) Redundant Chips);

[0044] The FPGA completes parallel computation within the same clock cycle:

[0045] Direct storage output (t0) = GCM authentication (PCM0(t0)∥256-bit MAC∥64-bit UTC timestamp),

[0046] And ∀t≠t0, direct storage output(t) = empty set;

[0047] The direct storage output (t0) simultaneously satisfies:

[0048] Local write address = NVMe-oF extended write (PCM0(t0));

[0049] Remote disaster recovery address = RDMA write(PCM0(t0)),

[0050] Make:

[0051] Recording (t0) = {Local PCM0(t0), Remote PCM0(t0)}

[0052] |t0 - Disk write complete| < 800ns, CPU utilization < 0.5%;

[0053] The formula is limited to generating non-empty output only at instant t0, and completing zero-copy, integrity verification, and peer disaster recovery replica generation with a single instruction.

[0054] A call recording watermarking system based on a telephone platform, using the same concept, includes:

[0055] The telephone platform is configured as follows:

[0056] Generate local raw call recordings;

[0057] Send a watermark request carrying the application ID and server IP to the watermarking platform;

[0058] Receive the encrypted digital watermark returned by the watermarking platform;

[0059] The encrypted digital watermark is embedded into the original recording locally using the echo watermarking module;

[0060] Upload the watermarked audio recordings to the file storage server;

[0061] The watermarking platform is configured as follows:

[0062] A unique digital watermark plaintext is generated in real time based on the received application ID and server IP and then encrypted with AES.

[0063] Save the application ID, server IP, and encrypted digital watermark to the database;

[0064] Return the encrypted digital watermark to the telephone platform;

[0065] During the verification phase, the watermark is extracted from the watermarked recording and compared with the database, and the verification result and corresponding information are returned.

[0066] File storage server for storing watermarked audio recordings;

[0067] The telephone platform and the watermarking platform only transmit encrypted digital watermarks and necessary request / response information, without transmitting the original or watermarked audio files.

[0068] The beneficial effects of this invention are:

[0069] 1. Disk write latency is reduced to less than 800ns, CPU usage is close to zero, and packet loss rate is reduced to 0.

[0070] 2. The watermark corresponds one-to-one with the caller's identity, time, and random factor, making the "recording-identity" inseparable.

[0071] 3. The verification process does not require the original plaintext recording, meeting high security and compliance requirements. Attached Figure Description

[0072] Figure 1 This is a functional architecture diagram of the present invention;

[0073] Figure 2 This is a flowchart of the synthetic watermark process of the present invention;

[0074] Figure 3 This is a flowchart of the extraction process of the present invention;

[0075] Figure 4 This is a system deployment architecture diagram of the present invention;

[0076] Figure 5 This is a sequence diagram of watermark generation-embedding-uploading according to the present invention;

[0077] Figure 6 This is a schematic diagram of the echo watermark embedding principle of the present invention;

[0078] Figure 7 This is the timing diagram of the signaling-triggered heterogeneous accelerated disk write-to-disk method of the present invention;

[0079] Figure 8 This is a flowchart of the watermark generation and rigid verification process of the present invention. Detailed Implementation

[0080] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0081] Reference Figures 1 to 8 The method for adding watermarks to call recordings based on a telephone platform, as shown, includes the following steps:

[0082] S1. Signaling-triggered heterogeneous acceleration disk recording: The telephone platform only starts the "zero kernel participation" heterogeneous acceleration channel at the moment the BYE signaling for the end of the call arrives. It uses a single atomic instruction to persist the voice data scattered in the user space buffer as the local original recording with zero copying, and simultaneously generates a disaster recovery copy for the peer end, eliminating disk recording delay and packet loss risk in one go.

[0083] Specifically, the implementation of step S1, "Signaling Triggered Heterogeneous Accelerated Disk Writing," is as follows: During the call duration, the telephone platform pre-allocates large page memory in user space as a circular buffer. The kernel is completely bypassed, and RTP voice packets are directly written to this buffer via the FPGA network card. Only when the call ends with the BYE signal arrives does the CPU execute a vector non-temporary storage instruction. This instruction atomically pushes the current metadata and length information of the buffer to the NVMe-oF user-space driver queue, simultaneously triggering the RDMA engine and DMA engine to work in parallel. The FPGA receives the instruction pulse within the same clock cycle and starts the hardware pipeline: first, it performs continuity verification on the RTP sequence number; if packet loss is detected, it immediately interpolates and fills in the frames; then, it reduces the sampling rate from 16 kHz to 8 kHz and calculates the AES-GCM integrity tag in the pipeline, generating PCM data blocks and their associated 256-bit message authentication codes. The host-side RDMA controller then writes the PCM data blocks to the remote persistent memory pool via NVMe-oF extended commands and writes them back to the local SSD using the Reed-Solomon(10,4) redundant chip, forming a disaster recovery copy for the peer. If the NVMe-oF link fails momentarily, the FPGA automatically switches to the redundant RDMA channel, splits the data, and writes it to the persistent memory of the remote node. Once the link is restored, the data is merged by a background coroutine. The entire process is completed within a single CPU clock cycle. Voice data is persisted from the user-space buffer to both local and remote persistence without kernel involvement or additional copying. No disk write operation occurs before the BYE signal arrives, ensuring disk write latency is below 800 nanoseconds and CPU usage is close to zero, thus eliminating the latency and packet loss risks in the traditional disk write path in one go.

[0084] S2, Minimal Watermark Request: After the disk is written, the telephone platform immediately requests a one-time encrypted digital watermark from the watermark platform with a single minimal message, and does not cache any watermark information locally;

[0085] The specific implementation of step S2, "Minimizing Watermark Request," is as follows: When the telephony platform detects an interruption in the heterogeneous accelerated disk write process, it immediately constructs a TLS 1.3 Early Data (0-RTT) extended message in user space. Its payload contains only a 16-byte application identifier and a 16-byte server IP address, with the overall length controlled within 64 bytes. Subsequently, the platform generates a 192-bit one-time random number using a hardware true random number generator and inserts this random number along with the first eight bytes of the TLS certificate SHA-256 digest into the same extension, forming anti-replay and platform identity binding information. After encapsulation, the telephony platform uses the established TLS Early Data channel to send this single-packet extension, retaining only the sending descriptor locally and not storing the random number, certificate fragments, or any data that might be used for watermark reconstruction later. Upon receiving the message, the watermarking platform queries the instantaneous request table using the random number as the key: if the key already exists, the request is discarded; if the key does not exist, the random number, application identifier, and server IP are written into the instantaneous request table, and the subsequent watermark generation process continues. The entire process involves watermark retrieval via a single round trip and a single packet. Neither the platform nor the terminal caches the plaintext watermark or key material, thus minimizing communication volume and leakage.

[0086] S3. Instantly generate verifiable watermarks: Upon receiving a request, the watermark platform generates a globally unique digital watermark in real time based on the caller's identity, timestamp, and random factor. After encryption, the watermark is fed back to the telephone platform, and a verifiable index is stored.

[0087] The specific implementation of step S3, "Instant Generation of Verifiable Watermark," is as follows: At the instant the TLS 1.3 handshake is completed and an interrupt is triggered, the watermarking platform directly reads the application identifier, server IP, 192-bit one-time random number, and UTC timestamp from the request message in the kernel's bypassed large page memory area. These four elements are then concatenated to form a plaintext block with a fixed format. Subsequently, the platform calls a hardware true random number generator to generate a 256-bit session key, encrypts the plaintext block using the AES-256-GCM algorithm, and simultaneously generates a 128-bit authentication tag. The ciphertext and tag together constitute the ciphertext form of the digital watermark. After encryption, the platform concatenates the session key and authentication tag, writes them into the volatile key slot of the Hardware Security Module (HSM), and establishes a hash mapping using a random number as input, forming a verifiable index that exists only within the HSM and cannot be directly read externally. Finally, the watermarking platform encapsulates the encrypted watermark and random number into a TLS application data record and immediately feeds it back to the telephone platform through the early data channel. The platform does not store any plaintext, key, or index copy locally, thus ensuring that watermark generation, index retention, and key management are all completed instantaneously and cannot be reverse-engineered.

[0088] S4. Locally Imperceptible Embedding: The telephone platform uses echo parameter space that is imperceptible to the human ear to embed the encrypted watermark into the original recording, forming a watermarked recording which is then uploaded to file storage.

[0089] This step is specifically as follows:

[0090] The implementation process of step S4, "locally imperceptible embedding," is as follows: After receiving the encrypted watermark, the telephone platform first divides the encrypted text into several blocks of 128 bits each. Each block is mapped to a pair of echo parameters based on its bit value: if the bit is "0," the echo delay is set to 0.5 milliseconds and the amplitude to -24 dB; if the bit is "1," the echo delay is set to 1 millisecond and the amplitude to -30 dB, thus forming a discrete bit-parameter lookup table. Subsequently, the platform opens a double buffer in user space, reads the original PCM data frame by frame with a frame length of 20 milliseconds, and simultaneously queries the above lookup table to instantly generate the corresponding echo kernel and perform convolution operation with the current frame. After the convolution result is saturated by a 16-bit signed integer, it is directly written back to the file handle. The entire process does not generate intermediate buffers or additional copies, forming a watermarked recording. After the embedding is completed, the platform sends the watermarked recording to the file storage server through the NVMe-oF PUT object interface. The metadata only contains the object name and length, without carrying any echo parameter information, thus ensuring that the sound quality change is imperceptible to the human ear while achieving a tight combination of encrypted watermark and original recording.

[0091] S5. One-to-one rigid verification: Any subsequent verification party can extract the watermark from the recording simply through the watermarking platform and compare it with the left index to trace back to obtain the original call identity and generation time, realizing an inseparable one-to-one rigid mapping of "recording-identity".

[0092] The specific implementation of step S5, "One-to-One Rigid Verification," is as follows: After the verifier uploads the recording file to be inspected to the watermarking platform via a TLS 1.3 bidirectional authentication channel, the platform immediately creates a read-only memory mapping in user space and slides through the entire recording frame by frame with a frame length of 20 milliseconds, extracting the embedded echo kernel frame by frame. Then, a matched filter is used to deconvolve each frame to reconstruct the complete bitstream. The bitstream is then decrypted using the same AES-256-GCM algorithm as in the embedding stage, yielding a quadruple containing the application identifier, server IP, a one-time random number, and a UTC timestamp. After decryption, the platform uses the random number as the unique key to query the session key and authentication tag stored in the volatile key slot within the Hardware Security Module (HSM). If the decrypted key and the tag data in the same slot are completely consistent, the platform returns the aforementioned quadruple to the verifier; otherwise, it returns an empty value. The entire verification process is performed only in the watermarking platform's memory, without storing the recording plaintext, decryption plaintext, or key materials on the ground, thus ensuring an inseparable one-to-one rigid mapping between "recording-identity."

[0093] Preferably, step S1, "signaling-triggered heterogeneous accelerated disk write," includes:

[0094] S11. During the call duration, the telephony platform pre-allocates a large-page circular buffer in user mode, and the kernel bypasses the reception of RTP packets. When the BYE signal arrives, the CPU executes an AVX-512 non-temporary storage instruction to write the buffer metadata into the NVMe-oF user-mode driver queue and simultaneously starts the RDMA engine and DMA engine.

[0095] S12. The FPGA network card enters the hardware pipeline under the same instruction pulse: sequentially executes RTP sequence number continuity check, packet loss interpolation compensation, 16kHz to 8kHz resampling and AES-GCM integrity tag calculation, and outputs PCM data block and its 256-bit MAC.

[0096] S13. The host RDMA controller writes PCM data blocks to the remote persistent memory pool through the NVMe-oF extended command, then generates Reed-Solomon(10,4) redundant chips and writes them back to the local SSD to form a disaster recovery copy for the peer.

[0097] S14. The above operations are completed within a single CPU clock cycle, with a disk write latency of less than 800ns and a CPU utilization rate of less than 0.5%. When the link fails, the FPGA switches to a redundant channel to continue writing.

[0098] Specifically, in step S11, during the call duration, the telephony platform pre-allocates large page memory in user mode and constructs a circular buffer; the FPGA network card at the network interface directly writes the received RTP packets into this buffer, and the kernel does not participate in data transfer. The moment the BYE signal arrives, the central processing unit executes an AVX-512 non-temporary storage instruction, atomically pushing the metadata and length information of the current buffer to the NVMe-oF user-mode driver queue, simultaneously triggering the RDMA engine and DMA engine to enter parallel operation.

[0099] Driven by the same clock pulse of S12, the FPGA network card immediately starts the hardware pipeline: first, it performs continuity verification on the RTP sequence number, and if a sequence number jump is detected, it immediately interpolates and fills in the frame; then, it reduces the sampling rate from 16 kHz to 8 kHz, and completes the AES-GCM integrity tag calculation in the pipeline, and finally outputs the PCM data block and its associated 256-bit message authentication code.

[0100] The S13 host-side RDMA controller writes PCM data blocks directly to the remote persistent memory pool via NVMe-oF extended commands, while simultaneously writing back the Reed-Solomon(10,4) redundant chip to the local solid-state drive to form a disaster recovery copy for the peer. If the NVMe-oF link fails momentarily, the FPGA automatically switches to the redundant RDMA channel, slices the data, and writes it to the persistent memory of the remote node. Once the link is restored, the background coroutine completes the merging.

[0101] S14 All the above operations are completed within a single CPU clock cycle. The entire path of voice data from the user-mode buffer to local and remote persistence is without kernel intervention or additional copying. The disk write time is less than 800 nanoseconds, and the CPU utilization is close to zero, thus eliminating the latency and packet loss risks in the traditional disk write path in one go.

[0102] Preferably, step S2, "minimizing watermark retrieval," includes:

[0103] S21. After disk writing is completed, the interruption triggers the telephone platform to construct a single packet TLS 1.30-RTT Extension. The payload contains a 16B application ID and a 16B server IP. The overall packet length is ≤64B.

[0104] S22, Extension adds 192-bit hardware true random number and the first 8 bytes of SHA-256 certificate fingerprint;

[0105] S23. The telephony platform sends the extension through the TLS early data channel, and only retains the sending descriptor locally, without caching random numbers, fingerprints and watermark information;

[0106] S24. The watermarking platform queries the instantaneous request table using a random number as the key. If the key exists, it is discarded; otherwise, the random number, application ID, and server IP are written into the table before watermark generation continues.

[0107] Specifically, after the S21 disk write-to-disk interrupt occurs, the telephony platform immediately constructs a TLS 1.3 0-RTT extended message in user space: the extended payload contains only a 16-byte application identifier and a 16-byte server IP address, with the overall length controlled within 64 bytes, forming a single-packet minimal request.

[0108] The S22 platform generates a 192-bit one-time random number on-site using a hardware true random number generator, and concatenates it with the first eight bytes of the local TLS certificate SHA-256 digest, appending it to the same extension for subsequent replay protection and platform identity binding.

[0109] S23 This extension is sent via the negotiated TLS early data channel; after the message leaves the network card, the telephony platform only retains the sending descriptor locally, without storing random numbers, certificate fragments or any watermark-related data, ensuring that there is no caching or leakage on the terminal side.

[0110] Upon receiving the extension, the S24 watermarking platform queries the instant request table using the random number as the unique key. If the key already exists, the request is discarded. If the key does not exist, the random number, application identifier, and server IP are written into the instant request table, and the subsequent watermark generation process continues. Thus, the entire retrieval process is completed in a single round trip using a single packet, minimizing communication volume and data exposure.

[0111] Preferably, step S3, "instantly generating a verifiable watermark," includes:

[0112] S31. When the TLS 1.3 handshake is interrupted, the watermarking platform reads the application ID, server IP, 192-bit random number and UTC timestamp from the request packet in the kernel bypass big page memory area and concatenates them to form a plaintext block.

[0113] S32. A hardware true random number generator is used to generate a 256-bit session key, which is then encrypted into a plaintext block using AES-256-GCM to generate a 128-bit authentication tag, together forming the digital watermark ciphertext.

[0114] S33. Concatenate the session key and the authentication tag and write them into the volatile key slot of the platform HSM. Establish a hash mapping between the slot address and the random number to form a verifiable index.

[0115] S34. The watermarking platform encapsulates the ciphertext and random number into a TLS application data record and immediately feeds it back to the telephone platform. The plaintext and session key are not stored locally.

[0116] Specifically, this step involves the S31 watermarking platform directly reading the application identifier, server IP, 192-bit one-time random number, and UTC timestamp from the request packet in the kernel bypass big page memory area at the moment the TLS 1.3 handshake is completed and interruption is triggered. The data is then concatenated into plaintext blocks in a fixed order without kernel copying.

[0117] The S32 platform calls the hardware true random number generator to generate a 256-bit session key, immediately uses the AES-256-GCM algorithm to encrypt the plaintext block, and generates a 128-bit authentication tag; the ciphertext and the tag together constitute the ciphertext form of the digital watermark.

[0118] After S33 encryption is completed, the platform concatenates the session key with the authentication tag, writes it into the volatile key slot of the Hardware Security Module (HSM), and establishes a hash mapping with a random number as input to form a verifiable index that exists only inside the HSM and cannot be read or exported from the outside.

[0119] S34 Finally, the watermarking platform encapsulates the ciphertext watermark and random number into a TLS application data record, and immediately feeds it back to the telephone platform through the early data channel. The platform does not store any plaintext, key or index copy locally, thus completing instant generation and verifiable index retention.

[0120] Preferably, step S4, "locally imperceptible embedding," includes:

[0121] S41. After receiving the digital watermarked ciphertext, the telephone platform divides it into 128-bit blocks, and each block is mapped to a pair of echo delays Δt∈{0.5 ms, 1ms} and amplitudes a∈{−24dB, −30dB}, forming a bit-parameter lookup table;

[0122] S42. In user space, open a double buffer, read the original PCM in 20ms frames, synchronously query the lookup table, and generate the corresponding echo kernel h(t)=α·δ(t−Δt) in real time, and convolve it with the original frame to complete the embedding.

[0123] S43. After the convolution output is saturated by INT16, it is directly written back to the file handle without generating intermediate buffer, thus forming a watermarked recording.

[0124] S44. The telephone platform sends watermarked recordings to file storage via the NVMe-oF PUT object interface. The metadata only contains the object name and length and does not carry echo parameters.

[0125] The specific steps are as follows: After receiving the encrypted watermark, the S41 telephone platform divides it into 128-bit units. Each bit value "0" is mapped to an echo delay of 0.5 milliseconds and an amplitude of -24 dB, and the bit value "1" is mapped to a delay of 1 millisecond and an amplitude of -30 dB. This establishes a discrete bit-parameter lookup table.

[0126] The S42 platform opens a double buffer area in user space and reads the raw PCM data segment by segment with a frame length of 20 milliseconds. While reading, it queries the above lookup table, generates the corresponding amplitude echo kernel in real time, and performs convolution operation with the current frame to complete the acoustic embedding of bit information.

[0127] After the S43 convolution result is saturated by a 16-bit signed integer, it is immediately written back to the same file handle. No intermediate buffers or extra copies are generated throughout the process, resulting in a watermarked audio file.

[0128] After the S44 is embedded, the platform sends the watermarked recording to the file storage server through the NVMe-oF PUT object interface. The object metadata only contains the file name and byte length, without carrying any echo parameters, thus achieving a tight combination of encrypted watermark and original recording while ensuring that the change in sound quality is imperceptible to the human ear.

[0129] Preferably, step S5, "one-to-one rigidity verification," includes:

[0130] S51. The verifier uploads the audio file to be inspected to the watermarking platform through the TLS 1.3 two-way authentication channel. The platform immediately creates a read-only memory mapping in user space and extracts the echo kernel h(t) by sliding at 20ms frames.

[0131] S52. Deconvolve each frame using a matched filter to restore the bitstream. After decryption using AES-256-GCM, obtain the quadruple {Application ID, Server IP, Random Number, UTC Timestamp}.

[0132] S53. Using the decrypted random number as the key, query the volatile key slot in the HSM. If the session key in the slot matches the authentication tag and the decryption result, output the quadruple; otherwise, return an empty value.

[0133] S54. The entire verification process is completed only in the platform's memory, without storing the recording or the decrypted plaintext on the ground.

[0134] The specific steps are as follows: After the S51 verifier uploads the audio file to be inspected to the watermarking platform via the TLS 1.3 two-way authentication channel, the platform immediately creates a read-only memory mapping in user space, slides through the entire recording with a frame length of 20 milliseconds, and extracts the embedded echo kernel features frame by frame.

[0135] The S52 platform uses a matched filter to deconvolve each frame to fully reconstruct the bitstream; then it uses the same AES-256-GCM algorithm as the embedding stage to decrypt the bitstream, obtaining a quadruple containing the application identifier, server IP, one-time random number, and UTC timestamp.

[0136] After S53 decryption is completed, the platform uses a random number as the unique key value to query the session key and authentication tag stored in the volatile key slot within the Hardware Security Module (HSM). If the decrypted key and tag data in the same slot are completely consistent, the platform outputs the above quadruple to the verifier. If the key value does not exist or the data is inconsistent, the platform returns an empty value.

[0137] The entire verification process of S54 is carried out only in the memory of the watermarking platform, without storing the plaintext of the recording, the plaintext of the decryption, or the key material on the ground, thereby ensuring that an inseparable one-to-one rigid mapping is formed between "recording and identity".

[0138] Preferably, the "signaling-triggered heterogeneous accelerated disk write" in step S1 satisfies the following formula condition:

[0139] Let the call end signaling arrive at time t0, defined as:

[0140] The remaining speech blocks in the loop buffer = ∑(i=0→N-1) frames[i], where frame[i] ∈ user-space big page buffer;

[0141] CPU executes a single vector non-temporal write instruction:

[0142] PCM0(t0) = Vector Stream Memory (Ring Buffer Address, Reordering Messages (Δt≤20μs)⊕RS(10,4) Redundant Chips);

[0143] The FPGA completes parallel computation within the same clock cycle:

[0144] Direct storage output (t0) = GCM authentication (PCM0(t0)∥256-bit MAC∥64-bit UTC timestamp),

[0145] And ∀t≠t0, direct storage output(t) = empty set;

[0146] The direct storage output (t0) simultaneously satisfies:

[0147] Local write address = NVMe-oF extended write (PCM0(t0));

[0148] Remote disaster recovery address = RDMA write(PCM0(t0)),

[0149] Make:

[0150] Recording (t0) = {Local PCM0(t0), Remote PCM0(t0)}

[0151] |t0 - Disk write complete| < 800ns, CPU utilization < 0.5%;

[0152] The formula is limited to generating non-empty output only at instant t0, and completing zero-copy, integrity verification, and peer disaster recovery replica generation with a single instruction.

[0153] To fulfill the formula condition of step S1, "signaling triggers heterogeneous accelerated disk writing," the system pre-allocates a large-page circular buffer in user space during the call duration. The kernel is completely bypassed, and RTP voice packets are directly written to the buffer by the FPGA network card, forming a continuous frame sequence. The central processing unit executes a vector non-temporary storage instruction only when the call end signal (BYE) arrives at the instant t0. This instruction atomically pushes the buffer's starting address and length metadata to the NVMe-oF user-space driver queue, simultaneously triggering the RDMA engine and DMA engine to enter parallel operation.

[0154] Within the same clock cycle, the FPGA receives a command pulse and initiates the hardware pipeline: first, it performs continuity verification on the RTP sequence number; if a transition is detected, it immediately interpolates and fills in the frame. Then, it reduces the sampling rate from 16 kHz to 8 kHz and completes the AES-GCM integrity tag calculation in the pipeline, generating PCM data blocks and their associated 256-bit message authentication codes to ensure data integrity. The host-side RDMA controller then writes the PCM data blocks directly to the remote persistent memory pool via NVMe-oF extended commands and writes back the Reed-Solomon(10,4) redundant chip to the local solid-state drive to form a peer disaster recovery copy. If the NVMe-oF link fails momentarily, the FPGA automatically switches to the redundant RDMA channel, slices the data, and writes it twice to the persistent memory of the remote node. Once the link is restored, the data is merged by a background coroutine.

[0155] The entire process described above is completed within a single CPU clock cycle. The voice data is persisted from the user-space buffer to the local and remote storage without kernel involvement or additional copying. No disk write operation is performed before the BYE signal arrives, ensuring that the disk write completion time is less than 800 nanoseconds and the CPU usage is close to zero, thereby eliminating the latency and packet loss risks in the traditional disk write path in one go.

[0156] A call recording watermarking system based on a telephone platform, using the same concept, includes:

[0157] The telephone platform is configured as follows:

[0158] Generate local raw call recordings;

[0159] Send a watermark request carrying the application ID and server IP to the watermarking platform;

[0160] Receive the encrypted digital watermark returned by the watermarking platform;

[0161] The encrypted digital watermark is embedded into the original recording locally using the echo watermarking module;

[0162] Upload the watermarked audio recordings to the file storage server;

[0163] The watermarking platform is configured as follows:

[0164] A unique digital watermark plaintext is generated in real time based on the received application ID and server IP and then encrypted with AES.

[0165] Save the application ID, server IP, and encrypted digital watermark to the database;

[0166] Return the encrypted digital watermark to the telephone platform;

[0167] During the verification phase, the watermark is extracted from the watermarked recording and compared with the database, and the verification result and corresponding information are returned.

[0168] File storage server for storing watermarked audio recordings;

[0169] The telephone platform and the watermarking platform only transmit encrypted digital watermarks and necessary request / response information, without transmitting the original or watermarked audio files.

[0170] To achieve the aforementioned "telephone platform-based call recording watermarking system with the same concept," the overall architecture is centered on the separation of powers between the telephone platform, the watermarking platform, and the file storage server. End-to-end protection is achieved through hardware-software collaboration, as detailed below:

[0171] Telephone platform configuration

[0172] Heterogeneous accelerated disk write module: During the call phase, a large-page circular buffer is pre-allocated in user space, and the kernel is completely bypassed; the moment the BYE signal arrives, the CPU executes a single vector non-temporary write instruction, triggering the FPGA-RDMA dual-engine parallel operation to complete zero-copy disk write between local and remote persistent memory, generating the original recording.

[0173] Minimize Request Module: After disk write is completed and an interrupt is triggered, a single packet TLS 1.3 0-RTT Extension is constructed. The payload contains only the application ID and server IP, with an additional hardware true random number and certificate fingerprint. It is sent to the watermarking platform in one go through the early data channel. Only the sending descriptor is retained locally, and no watermark information is cached.

[0174] Echo embedding module: After receiving the returned encrypted watermark, it is divided into 128-bit blocks and mapped to echo delay and amplitude parameters. It is then convolved with the original PCM in real time with a frame length of 20 ms. After saturation discrimination, the convolution result is directly written back to the file handle to form a watermarked recording.

[0175] Upload Interface: Watermarked recordings are sent to the file storage server via the NVMe-oF PUT object interface. The metadata only contains the object name and length, and does not carry echo parameters.

[0176] Watermarking platform side configuration

[0177] Instantaneous generation module: When the TLS handshake is interrupted, it reads the application ID, server IP, random number and UTC timestamp from the request packet and concatenates them into a plaintext block; a 256-bit session key is generated by a hardware true random number generator and encrypted with AES-256-GCM to generate a ciphertext watermark and a 128-bit authentication tag.

[0178] Verifiable Index Module: Writes the session key and authentication tag into the HSM volatile key slot, establishes a hash mapping with random numbers as input, and forms an index that can only be accessed internally by the HSM and cannot be exported externally.

[0179] Rigid verification module: After receiving the recording to be verified uploaded by the verifier, it creates a read-only memory mapping in user space, performs sliding deconvolution in 20ms frames to restore the bitstream, and decrypts it using AES-256-GCM to obtain a quadruple; it then queries the HSM slot using a random number as the key. If the key matches the tag, it outputs the quadruple; otherwise, it returns an empty value. The entire verification process is completed only in the platform's memory, without storing the recording or plaintext on the hard drive.

[0180] File storage server configuration

[0181] It only provides a standard object storage interface to save watermarked recording objects, but does not save any watermark keys, indexes or plaintext information, and there is no watermark-related control signaling interaction with the telephone / watermarking platform.

[0182] Information segregation principle

[0183] The telephone platform and the watermarking platform only transmit ≤64 B encrypted watermarks and one-time random numbers, without transmitting the original or watermarked recordings; the recording files are only exchanged between the telephone platform and the file storage server through the NVMe-oF channel, realizing the separation of "recording-watermarking-index". If any single node is compromised, it will be impossible to obtain the plaintext recording, key and verification index at the same time, thus meeting the rigid identity binding requirements in high-security scenarios.

[0184] By adopting the above-disclosed technical solution of this invention, the following beneficial effects are obtained:

[0185] Disk write completion time is less than 800ns, CPU usage is close to zero, and packet loss rate is reduced to 0, solving the risks of latency and packet loss in traditional paths;

[0186] Watermark request packets are ≤64B each, terminal has zero key caching, and communication and leakage planes are compressed to the minimum.

[0187] The watermark corresponds one-to-one with the caller's identity, time, and random number. The HSM index and recording are stored separately, achieving an inseparable one-to-one rigid mapping between "recording and identity".

[0188] The verification process does not require the original plaintext recording; it is completed within the platform's memory, and the key or decryption data is not stored on the ground, thus meeting the highest level of compliance requirements.

[0189] The separation of powers architecture ensures that if any one of the nodes—the audio file, the watermarked encrypted text, or the verification index—is compromised, the complete information cannot be recovered, providing systemic security redundancy.

[0190] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for adding watermarks to call recordings based on a telephone platform, characterized in that, Includes the following steps: S1. Signaling-triggered heterogeneous acceleration disk recording: The telephone platform only starts the "zero kernel participation" heterogeneous acceleration channel at the moment the BYE signaling for the end of the call arrives. It uses a single atomic instruction to persist the voice data scattered in the user space buffer as the local original recording with zero copying, and simultaneously generates a disaster recovery copy for the peer end, eliminating disk recording delay and packet loss risk in one go. S2, Minimal Watermark Request: After the disk is written, the telephone platform immediately requests a one-time encrypted digital watermark from the watermark platform with a single minimal message, and does not cache any watermark information locally; S3. Instantly generate verifiable watermarks: Upon receiving a request, the watermark platform generates a globally unique digital watermark in real time based on the caller's identity, timestamp, and random factor. After encryption, the watermark is fed back to the telephone platform, and a verifiable index is stored. S4. Locally imperceptible embedding: The telephone platform uses the echo parameter space, which is imperceptible to the human ear, to embed the encrypted watermark into the original recording, forming a watermarked recording, which is then uploaded to the file storage. S5. One-to-one rigid verification: Any subsequent verification party can extract the watermark from the recording simply through the watermarking platform and compare it with the left index to trace back to obtain the original call identity and generation time, realizing an inseparable one-to-one rigid mapping of "recording-identity".

2. The method according to claim 1, wherein, The step S1, "Signaling Triggered Heterogeneous Accelerated Disk Writing", includes: S11. During the call duration, the telephony platform pre-allocates a large-page circular buffer in user mode, and the kernel bypasses the reception of RTP packets. When the BYE signal arrives, the CPU executes an AVX-512 non-temporary storage instruction to write the buffer metadata into the NVMe-oF user-mode driver queue and simultaneously starts the RDMA engine and DMA engine. S12. The FPGA network card enters the hardware pipeline under the same instruction pulse: sequentially executes RTP sequence number continuity check, packet loss interpolation compensation, 16kHz to 8kHz resampling and AES-GCM integrity tag calculation, and outputs PCM data block and its 256-bit MAC. S13. The host RDMA controller writes PCM data blocks to the remote persistent memory pool through the NVMe-oF extended command, then generates Reed-Solomon(10,4) redundant chips and writes them back to the local SSD to form a disaster recovery copy for the peer. S14. The above operations are completed within a single CPU clock cycle, with a disk write latency of less than 800ns and a CPU utilization rate of less than 0.5%. When the link fails, the FPGA switches to a redundant channel to continue writing.

3. The method according to claim 2, wherein, Step S2 "Minimize watermark retrieval" includes: S21. After disk writing is completed, the interruption triggers the telephone platform to construct a single packet TLS 1.30-RTT Extension. The payload contains a 16B application ID and a 16B server IP. The overall packet length is ≤64B. S22. The Extension adds a 192-bit hardware true random number and the first 8 bits of the SHA-256 certificate fingerprint; S23. The telephony platform sends the extension through the TLS early data channel, and only retains the sending descriptor locally, without caching random numbers, fingerprints and watermark information; S24. The watermarking platform queries the instantaneous request table using a random number as the key. If the key exists, it is discarded; otherwise, the random number, application ID, and server IP are written into the table before watermark generation continues.

4. The method according to claim 3, wherein, Step S3, "Instantly generate a verifiable watermark," includes: S31. When the TLS 1.3 handshake is interrupted, the watermarking platform reads the application ID, server IP, 192-bit random number and UTC timestamp from the request packet in the kernel bypass big page memory area and concatenates them to form a plaintext block. S32. A hardware true random number generator is used to generate a 256-bit session key, which is then encrypted into a plaintext block using AES-256-GCM to generate a 128-bit authentication tag, together forming the digital watermark ciphertext. S33. Concatenate the session key and the authentication tag and write them into the volatile key slot of the platform HSM. Establish a hash mapping between the slot address and the random number to form a verifiable index. S34. The watermarking platform encapsulates the ciphertext and random number into a TLS application data record and immediately feeds it back to the telephone platform. The plaintext and session key are not stored locally.

5. The method according to claim 4, wherein, Step S4, "Locally Unaware Embedding," includes: S41. After receiving the digital watermarked ciphertext, the telephone platform divides it into 128-bit blocks, and each block is mapped to a pair of echo delays Δt∈{0.5 ms, 1ms} and amplitudes a∈{−24dB, −30dB}, forming a bit-parameter lookup table; S42. In user space, open a double buffer, read the original PCM in 20ms frames, synchronously query the lookup table, and generate the corresponding echo kernel h(t)=α·δ(t−Δt) in real time, and convolve it with the original frame to complete the embedding. S43. After the convolution output is saturated by INT16, it is directly written back to the file handle without generating intermediate buffer, thus forming a watermarked recording. S44. The telephone platform sends watermarked recordings to file storage via the NVMe-oF PUT object interface. The metadata only contains the object name and length and does not carry echo parameters.

6. The method according to claim 5, wherein, Step S5, "One-to-One Rigid Verification," includes: S51. The verifier uploads the audio file to be inspected to the watermarking platform through the TLS 1.3 two-way authentication channel. The platform immediately creates a read-only memory mapping in user space and extracts the echo kernel h(t) by sliding at 20ms frames. S52. Deconvolve each frame using a matched filter to restore the bitstream. After decryption using AES-256-GCM, obtain the quadruple {Application ID, Server IP, Random Number, UTC Timestamp}. S53. Using the decrypted random number as the key, query the volatile key slot in the HSM. If the session key in the slot matches the authentication tag and the decryption result, output the quadruple; otherwise, return an empty value. S54. The entire verification process is completed only in the platform's memory, without storing the recording or the decrypted plaintext on the ground.

7. The method according to claim 1, wherein, In step S1, "signaling triggers heterogeneous accelerated disk write" satisfies the following formula condition: Let the call end signaling arrive at time t0, defined as: The remaining speech blocks in the loop buffer = ∑(i=0→N-1) frames[i], where frame[i] ∈ user-space big page buffer; CPU executes a single vector non-temporal write instruction: PCM0(t0) = Vector Stream Memory (Ring Buffer Address, Reordering Messages (Δt≤20μs)⊕RS(10,4) Redundant Chips); The FPGA completes parallel computation within the same clock cycle: Direct storage output (t0) = GCM authentication (PCM0(t0)∥256-bit MAC∥64-bit UTC timestamp), And ∀t≠t0, direct storage output(t) = empty set; The direct storage output (t0) simultaneously satisfies: Local write address = NVMe-oF extended write (PCM0(t0)); Remote disaster recovery address = RDMA write(PCM0(t0)), Make: Recording (t0) = {Local PCM0(t0), Remote PCM0(t0)} |t0 - Disk write complete| < 800ns, CPU utilization < 0.5%; The formula is limited to generating non-empty output only at instant t0, and completing zero-copy, integrity verification, and peer disaster recovery replica generation with a single instruction.

8. A call recording watermarking system based on a telephone platform, characterized in that, include: The telephone platform is configured as follows: Generate local raw call recordings; Send a watermark request carrying the application ID and server IP to the watermarking platform; Receive the encrypted digital watermark returned by the watermarking platform; The encrypted digital watermark is embedded into the original recording locally using the echo watermarking module; Upload the watermarked audio recordings to the file storage server; The watermarking platform is configured as follows: A unique digital watermark plaintext is generated in real time based on the received application ID and server IP and then encrypted with AES. Save the application ID, server IP, and encrypted digital watermark to the database; Return the encrypted digital watermark to the telephone platform; During the verification phase, the watermark is extracted from the watermarked recording and compared with the database, and the verification result and corresponding information are returned. File storage server for storing watermarked audio recordings; The telephone platform and the watermarking platform only transmit encrypted digital watermarks and necessary request / response information, without transmitting the original or watermarked audio files.

Images