{'fraction_non_alphanumeric': 0.030819377318197144, 'fraction_numerical': 0.007867820613690008, 'mean_word_length': 4.723144217161971, 'pattern_counts': {'":': 0, '<': 4, '<?xml version=': 0, '>': 6, 'https://': 1, 'lorem ipsum': 0, 'www.': 1, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
VoiceMask: Anonymize and Sanitize Voice Input on Mobile Devices

Voice input has been tremendously improving the user experience of mobile devices by freeing our hands from typing on the small screen. Speech recognition is the key technology that powers voice input, and it is usually outsourced to the cloud for the best performance. However, the cloud might compromise users' privacy by identifying their identities by voice, learning their sensitive input content via speech recognition, and then profiling the mobile users based on the content. In this paper, we design an intermediate between users and the cloud, named VoiceMask, to sanitize users' voice data before sending it to the cloud for speech recognition. We analyze the potential privacy risks and aim to protect users' identities and sensitive input content from being disclosed to the cloud. VoiceMask adopts a carefully designed voice conversion mechanism that is resistant to several attacks. Meanwhile, it utilizes an evolution-based keyword substitution technique to sanitize the voice input content. The two sanitization phases are all performed in the resource-limited mobile device while still maintaining the usability and accuracy of the cloud-supported speech recognition service. We implement the voice sanitizer on Android systems and present extensive experimental results that validate the effectiveness and efficiency of our app. It is demonstrated that we are able to reduce the chance of a user's voice being identified from 50 people by 84% while keeping the drop of speech recognition accuracy within 14.2%.


I. INTRODUCTION
Featuring hand-free communication, voice input has been widely applied in keyboard apps (e.g. Google, Microsoft, Sougou, and iFlytek keyboards), voice search (e.g. Microsoft Bing, Google Search) and artificial intelligence personal assistants (e.g. Apple's Siri, and Amazon Echo) on a range of mobile devices. Voice input can greatly ease our lives by freeing our hands and attention from the time-consuming work of typing on the small screen of mobile devices. It is also one of the major means of human-computer communication for people who are visually impaired. The key technology that powers voice input is speech recognition, also known as speech-to-text conversion, where the vocal input of spoken language is recognized and translated into texts. Due to the resource limitation on mobile devices, the speech recognition is usually outsourced to the cloud server for higher accuracy and efficiency [10], [18], which are two key elements leading to a good user experience for voice input systems. However, most of the existing voice input service providers collect their users' speech records 1 . Because the voice datasets, once correlated with the identities of the speakers, will reveal various private information describing the individuals, we argue that the Personally Identifiable Information (PII) should not be disclosed to the cloud (e.g., MAC addresses/Device IDs/User IDs associated with the datasets). This can be achieved by leveraging existing anonymous networks such as Tor [7], [8]. However, with such a naïve sanitization voice records can still be de-anonymized by linkage attacks with the speaker recognition technology. Linkage attacks are possible because different individuals have different voice characteristics (i.e., voice biometrics), and such voice biometrics can serve as fingerprints of the speech datasets.
In this paper, our goal is to protect the speech data privacy for voice input users while maintaining the user experience. Our strategy, in general, is to perturb the speech data in order to remove the personally identifiable voice fingerprints for the sake of complete anonymity for individual users. Our research also benefits existing voice input service providers by providing them with better data security. Because users' privacy is preserved at the data level and no individuals will be identified from the datasets the companies possess, they are less likely to be held responsible for the privacy leak caused by data breach once it occurs.
We are facing two privacy risks in the cloud-based voice input services. On one hand, the cloud (or third parties who obtained the voice data from the cloud) may link the speech records to individuals in real life by harnessing the speaker recognition technology. If the cloud is able to collect some speech samples of the target person from other sources like YouTube and train a voice model of this person, then it can identify the records belonging to this person from the speech database, which leads to the user's identity privacy breach. On the other hand, the cloud can also analyze the content of users' speeches and learn more detailed private information. The cloud may use natural language processing techniques to extract information from a user's voice search history, voice command history, and even SMS messages and emails if they were typed via voice input, which leads to the user's content privacy breach. Then the cloud can paint a very accurate picture of the user's demographic categories, personal preferences, interpersonal communications, habits, schedules, and travels. Therefore, the risk of privacy disclosure from speech data is real, and we believe it is very necessary to come up with countermeasures and stop the leak of privacy from its source, that is, our smart mobile devices.
There are also serious security risks of existing voice input service architecture, such as spoofing attack to speaker authentication systems. Voice as a type of biometric information has been widely used in emerging authentication systems to unlock smart devices, gain access to some apps like WeChat, and activate services like Apple's "Hey Siri" and Google's "OK Google". Once the cloud collects enough voice samples from a user, it can create an accurate voice print and use it to synthesize other speeches that sound like this user [13], [34], which may be exploited to spoof the voice authentication systems and gain access to the user's private resources. Worse still, the leaked voice can be used for fraud or to produce illegal recordings to frame and blackmail the person [3], [6].
In order to mitigate the aforementioned two privacy risks and avoid the security risk, we have two corresponding subgoals in privacy preservation: 1) preserving the users' identity privacy and 2) preserving their speech content privacy. The challenges are fourfold. Firstly, we have to sanitize users' speech data without degrading the accuracy of speech-to-text conversion to an unacceptable extent. In other words, the users can still use the voice input app to transform their voice into text with high accuracy as before. We should ensure the accuracy of speaker recognition on the sanitized data by the cloud is greatly decreased while the accuracy of speech recognition on them is well preserved. Secondly, it is challenging to protect speech content privacy because it requires us to solve three sub-questions: what information is considered sensitive/private? how to locate the sensitive content within the speech? how to hide the sensitive content without influencing the user experience? Thirdly, speech as a type of unstructured data is hard to be processed in a privacypreserving manner. Traditional secure multi-party computation methods cannot be employed directly. Cryptographic tools like searchable encryption for information retrieval do not apply to speech recognition either. Lastly, it is hard to perform speech sanitization in real-time efficiently with the restricted resources on the mobile device. The computation overhead should be small enough to induce acceptable latency for the voice input apps. The power consumption by the sanitization process should also be limited.
The naïve method is to simply perform speech recognition locally without the help from the cloud. No privacy is leaked in this way, but the performance of offline speech recognition is inferior due to the limited computing resources on mobile devices [20]. The local speech models cannot be updated timely as well. On the other hand, the cloud already provides free services so they tend to collect data as much as possible. Most of these companies are unwilling to release offline speech recognition products. Google Nexus allows us to use offline voice typing but only when we are disconnected from the Internet. As a result, we cannot expect the cloud to provide unconditional offline speech recognition service for users and we still have to rely on the powerful cloud to support more accurate speech recognition. To protect privacy, we need to sanitize the speech data on the mobile device before sending it to the cloud for speech recognition.
Our solution: To ensure the cloud has access to only the sanitized speech data, our basic solution is to introduce an intermediary app (referred to as "VoiceMask" hereafter) to perturb the speeches. It acts as a third-party voice input app that connects users' mobile devices to the speech recognition cloud. The voice sanitizer processes the audio signal received from the microphone and then sends the sanitized speech audio to the cloud. The sanitization is conducted from two aspects: (1) It disguises the speaker's identity by randomly modifying the speaker's voice using the voice conversion technology, and (2) it perturbs the contents of voice input via keyword substitution to hide the sensitive information from being disclosed to the cloud. The two complementary perturbations performed locally in real time on the speech data ensure that the cloud (and the voice input app) learns neither users' identity nor their private input contents.
Contributions: To the best of our knowledge, VoiceMask is the first privacy-preserving architecture for the voice input function on mobile devices. We decouple the voice input app and the cloud to prevent the cloud from learning users' private information through the app (Section III). We then propose two light-weighted techniques for mobile devices to protect user identity and voice input content from being leaked to cloud servers. The user identity privacy is preserved by a voice conversion technique that is resistant to the reversing attack or the reducing attack (Section IV-A). The input content privacy is preserved by a randomized keyword substitution heuristic, consisting of an evolution-based keyword spotting method for sensitive word detection and a differentially private algorithm for safeword set construction (Section IV-B). We implement VoiceMask on Android systems and conduct extensive evaluation (Section V).

A. System and Adversary Models
The voice input service provider usually consists of an app on the user end and the cloud that performs speech recognition. We assume it is honest but curious. It honestly executes the pre-designed protocol and provides a good user experience of voice input, but it might exploit the data it can access to learn the user's sensitive information. We also assume the data collected by the cloud is anonymous. For example, Apple has applied privacy-enhancing techniques to prevent their data analysts from seeing the user accounts associated with the data 2 . Meanwhile, users who wish to achieve full anonymity can employ the anonymous network to stop the cloud from obtaining their PII. Please note this paper aims to defend against only voice input apps (and their cloud). There are certainly many other apps undermining our privacy, like browsers and emails, but how to defend against them is not our focus.

B. Privacy Risks
Most voice input service providers collect their users' speech data. For instance, Apple stores our Siri voice commands for 24 months [1] and Google stores everything we say to Google Now by default [4]. Thought they claim they will not sell our data in the privacy policy, they do analyze our data, which may compromise our privacy. There are two types of privacy in this paper's scope: identity privacy and content privacy.
To attack the identity privacy of a target person, the service provider may gather the person's speech audios from another source, for example from her YouTube channel or her posts on online social media. Then, a voice model that represents the person's voice biometrics can be trained in order to identify her utterances in the stored speech database. In 2014, GoVivace Inc. started to provide speaker identification SDK for telecom companies to infer the caller's identity by matching her voice with a database containing thousands of voice recordings. In our experiment, we can identify one person out of 250 candidates with a 100% success rate given that we have collected several speeches of this person (as short as 30 seconds). The detailed settings of this experiment will be presented in Section V-A. Once a person's utterances is identified, the service provider will be able to mine more private information from the speech content.
Furthermore, the voice service provider may also invade users' content privacy. After executing speech recognition, the service provider can extract personal information from user's utterances using natural language processing techniques. Some of the information within the utterances could be sensitive, e.g. demographic attributes, personal preferences, schedules, and interpersonal relations. Thus, the content privacy of users' speech data could be disclosed. Such privacy issue is always 2 Apple's privacy policy on data analytics, https://www.apple.com/privacy/approach-to-privacy/ a serious concern when we use any cloud-based speech recognition service.
Although these two types of privacy concerns are quite different, they may lead to a worse privacy breach if combined together. For example, with detected sensitive contents (such as phone number or home address) from the speech recognition, the speaker can be easily identified. even from a huge candidate pool. Therefore, we have to address these two types of privacy risks simultaneously.

A. System Architecture
A sketch of the privacy-preserving voice input system is depicted in Fig. 1. The cloud is a server dedicated to providing speech-to-text service. It does not install apps on the mobile end. Instead, the voice sanitizer (like a keyboard app) bridges the communication between the user, the cloud, and third party apps. It is trusted, e.g. it can release the source code to the public. The voice sanitizer accesses the raw audio, perturbs it, and produces sanitized audio which contains much less private information about the user. After the sanitized speech is sent to the cloud and the corresponding transcript is sent back, the voice sanitizer revokes some of previous perturbations on it and restores it to the desired transcript. Finally, the transcript is copied to the input box of any other app on the device that has requested user input before. Notice that the voice sanitizer is locally deployed in mobile devices, and it is independent of the cloud service provider. Such separation prevents the cloud from collecting private information from the user device.
The internal system architecture of the voice sanitizer is illustrated in Fig. 2. Given a stream of raw audio signals, the sanitization process can be divided into two modules: keyword substitution and voice conversion. The whole process can be explained with a simple example. Suppose a user is writing a text message to a friend. She reads a sentence to the mic, "I'd love to, but I have to attend a group therapy tomorrow". Suppose she has set "group therapy" as a sensitive keyword previously, the voice sanitizer detects its occurrence within the speech and then substitutes it with a selected safeword "meeting". Then, the voice sanitizer converts the speech to another voice and sends the sanitized speech to the cloud. The cloud performs speech recognition and sends back the perturbed transcript "I'd love to, but I have to attend a meeting tomorrow". Finally, the voice sanitizer reverses the substitution and copies the desired text to the input box of the SMS app. In this process, the sensitive information contained in the original speech is not disclosed to the cloud. Nor is the user's voice characteristics, which otherwise might be utilized for linkage attacks or spoofing attacks. This is only an illustrative instance. More issues and detailed solutions will be introduced later.

B. Adaptive Keyword Substitution
Protecting content privacy is very challenging as content privacy is hard to define, let alone protecting it on unrecognized speeches. To achieve this goal, we focus on a simplified case: sensitive keyword substitution on the speeches. As shown in Fig 2, the process of keyword substitution contains two stepskeyword spotting and safeword substitution. Our approach first detects the specified sensitive keywords and then replaces them with carefully selected safewords. Here, the sensitive keywords are predefined by the users. They could be nouns like "hospital" and "addiction", verbs like "smoke" and "bribe", adjectives like "alt-left" and "alt-right". The user needs to read each keyword for at least one time to train the voice sanitizer, and the STFT features of these utterances (referred to as keyword samples) will be kept for keyword spotting. The set of safewords is predefined by our system and identical to all users. The keyword spotting and safeword substitution must be done in real-time with light computation cost. We achieve such goals by limiting the number of keywords defined by users and a simple DTW (dynamic time warping) based method.

Pitch
Keyword spotting identifies keywords directly from the utterances. It is usually used for keyword monitoring, speech document indexing, and automated dialogue systems [11], [37]. We design an adaptive keyword spotting mechanism based on DTW, which is well suited for real-time scenarios. The general idea is straightforward. The voice sanitizer scans the input audio stream and computes the distance between the audio signal within a sliding window and the sensitive keyword samples recorded by the user previously. A DTW algorithm is applied here to calculate the distance of two signals, which can address the issue of dynamic speak rate and various audio lengths. STFT features are computed and cosine distance is used as the metric. If the distance between the signal of the speech segment being scanned and the signal of the keyword sample is below a certain threshold θ, the corresponding segment is considered as a sensitive keyword.
However, to realize this idea, there is one more obstacle: liaison, a very common phenomenon in English pronunciation. The existence of liaison enlarges the distance between two identical words if they occur in different contexts. For example, the word "apple" can be pronounced as "napple" in the context of "an apple". Thus, directly comparing the extracted voice signals without considering liaison would lead to a high false negative rate. To handle this issue, we introduce an evolutionary model for representing the keywords. For a given keyword, the stored keyword sample evolves over time.
When the user speaks a sentence containing this keyword and it is correctly detected by our app (a hit), the stored keyword sample will update itself with this new audio sample. (The voice sanitizer would know a detected keyword is indeed a hit if the user does not revise the text recognized by it.) Let When α < 0, the low frequency part of the frequency axis is compressed and the high frequency part is stretched. When α > 0, the low frequency part is stretched while the high frequency part is compressed. Fig. (b) gives an example of the spectrogram of a speech before and after its frequencies are warped.
x be the feature vector of a stored keyword sample, y be the feature vector of the i-th correctly detected keyword, and φ(y) represents the warped feature vector after DTW processing.
To update the existing keyword sample, each element of x is updated by the following equation.
This updating process mitigates the impact of liaison by laying more emphasis on the middle part. We also allow users to point out the missed keyword and improve the corresponding recorded keyword in the same way. Safeword substitution: After spotting the keyword, we replace it with a word chosen at random from the safeword set. Voice sanitizer will keep the log of such replacement, which enables re-substituting the safeword back after receiving the perturbed transcript from the cloud. This randomized substitution also avoids the privacy leakage from choosing safeword. We will present more details in Section IV-B.

C. VTLN-Based Voice Conversion
To protect identity privacy for users of voice input service, we design a mechanism on top of the voice conversion technology. Voice conversion algorithm modifies a source speaker's voice so that it sounds like another target speaker without changing the language contents. One of the most popular voice conversion paradigms is frequency warping [29], which is based on the well-studied technique of vocal tract length normalization (VTLN) [12], [15]. Given a source utterance, VTLN-based voice conversion processes it in 6 steps (Fig.  2). Pitch marking and frame segmentation aim to split the speech signal into frames that match the pseudo-periodicity of voiced sounds as determined by the fundamental frequency of the voice, so as to make the output synthetic voice have the best audio quality. The key step of voice conversion is VTLN, which modifies the spectrum of each frame using frequency warping, that is, stretching or compressing the spectrum with respect to the frequency axis according to a warping function. One of the most commonly used warping function is the bilinear function [9], [29]. The formula of this function is: where ω ∈ [0, π] is the normalized frequency, α ∈ (−1, 1) is a warping factor used to tune the strength of voice conversion, i is the imaginary unit and z = e iω . Several examples of the bilinear function are plotted in Fig. 3. Given a frequencydomain data frame, every frequency ω is changed to a new frequency f (ω, α) by this formula. Then all the frequencywarped frames are reverted to the time domain by IFFT. Finally, all the frames are concatenated to generate the output speech, and a technique PSOLA is utilized to improve the speech quality [31]. Therefore, an utterance is produced with the same language content but a different voice. This is the basic idea of protecting the identity privacy, yet it is not that easy. There are several issues to consider, including how to minimize the influence on the audio quality of the output speech and how to select α to achieve a strong privacy guarantee. We will discuss the details in Section IV-A.

A. Protecting User Identity Privacy
When we disguise the speaker's identity by randomly modifying her/his voice to another voice, it is required that the speech content can still be accurately recognized when it is uploaded to the cloud so that user experience is not degraded unacceptably. As aforementioned, the parameter α in the bilinear function tunes the extent of distortion of the output voice. Setting α < 0 would produce a deeper (more like lowpitched) output voice; setting α > 0 would produce a sharper (more like high-pitched) output voice. The greater |α| is, to a higher extent the output voice is distorted. The output voice is not distorted at all when α is 0. (See Fig. 3 for the reason.) We want to select the best α that can bring a considerable drop in the speaker recognition accuracy whereas the decrease of the speech recognition accuracy is minimized. However, finding the best value of α is not enough, because if we always use the same α to transform a user's voice to the same fake voice, the cloud may build a model on this fake voice and use it to recognize this user afterward. In addition, the cloud may find the value of α by decompiling the apk of the voice sanitizer, and then reverse the voice conversion to recover the original voice. Reversing voice conversion attack is possible because the warping functions are invertible. Take bilinear functions as an example, f (w, −α) is the inverse function of f (w, α). Therefore, we need to find a proper range of α and randomly choose α from this range every time. Now the question is, what is the proper range and how randomly should we choose α from it to ensure reversing voice conversion is impossible?
Randomized warping factor selection: Suppose the proper range of the warping factor α is A. In fact, we found A = [−0.10, −0.08] ∪ [0, 08, 0.10] experimentally (we will present details in Section V-B1). Every time the user speaks a sentence, the voice sanitizer randomly selects α ∈ A, uses Eq. (2) to warp the frequency of the speech and then sends it to the cloud. The cloud receives speeches in different voices even when they are from the same user, so it is almost impossible to directly use the previously trained voice models to recognize the user's identity.
However, there is still a possibility that the cloud can reduce ("partially reverse") the voice conversion to a weaker level so that it can achieve a higher speaker recognition accuracy. The bilinear function f (ω, α) we adopt has a property: That said, applying voice conversion twice to a speech with α 1 and α 2 successively yields exactly the same output as applying the voice conversion once with α = α 1 +α 2 . Suppose the cloud has received many sanitized speeches from users whose voices have been converted with α ∈ [0.10, 0.12]. It can apply a second voice conversion to these speeches with α 2 = −0.11. Now the produced speeches are actually the output speeches of voice conversion with α ∈ [−0.01, 0.01], which has much weaker distortion strength than the originally sanitized speeches. Consequently, the cloud can achieve better accuracy than we originally expected when performing speaker recognition on these speeches. We refer to this process as reducing voice conversion attack, and we say a function is reducible if it has the property in Eq. (3). To our knowledge, this issue has not been studied in previous research papers.
Besides the bilinear function, other common warping functions like the symmetric function [30], the power function [15] and the quadratic function [25] are also reducible. Therefore, a more complex mechanism must be designed. Secure compound warping functions: To design a warping function that is resistant to the reducing voice conversion attack, our technique is to compound two different warping functions. Here we introduce another commonly used warping function that is easy to tune, the quadratic function [25]: where ω ∈ [0, π] is the normalized frequency and β > 0 is a warping factor. Similar to α in the bilinear function, β determines the distortion strength of this function. The output voice turns deeper when β < 0 and sharper when β > 0. Luckily, the compound function of f and g (denoted as h) is not reducible. The formula of h is: h(ω, α, β) = g(f (ω, α), β). Since the two independent parameters α, β are used in combination, they have a much bigger proper range (will be studied in Section V-B3). Now if every time the voice sanitizer perturbs a speech from the user, it randomly picks a pair of values for α, β from this range as the warping factors. This mechanism ensures the cloud is unable to reverse or reduce the voice conversion.
However, it is challenging to learn the combined impact of α, β on the distortion level of the output voice. To estimate it, we need to first quantify the distortion strength of the warping function h. An intuition is that the closer h is to the identity function, the less distortion h brings to the output voice. Take Fig. 3(a) as an example, the closer the bilinear function is to the identity function, the closer α is to 0, and the less distortion it produces on the output voice. This way, we can measure the distortion strength of h by the area between the curves of itself and the identity function.
Definition 1 (Distortion strength): The distortion strength (denoted as dist) of a warping function f (ω, a) is defined as the area between the curves of itself and the identity function, i.e. dist f (a) = π 0 | f (ω, a) − ω |, where a represents the warping factors. We will discuss how to find the proper range using this definition in Section V-B3.

B. Protecting Speech Content Privacy
Content privacy is achieved by substituting sensitive keywords with safewords, so the first task is to construct a safeword set.
Differentially private safeword set construction: We don't want to replace a keyword in a user's speech with a more sensitive word because this would harm her personal reputation, for instance, when the keyword "doctor" in "I need to see my doctor" is changed to "probation officer". Thus, we need to avoid putting common sensitive words in the safeword set. But how does the voice sanitizer know which words are usually sensitive? We introduce a new central server that connects all the voice sanitizer apps and collects the keywords defined by users for statistics. The server ranks these keywords by frequency and then knows which words are commonly viewed as sensitive. Nevertheless, we cannot fully trust the server. Directly sending each user's sensitive keywords to the server would break their privacy. Inspired by [16], we design a privacy-preserving randomized keyword aggregation algorithm (PRAKA) that achieves differential privacy based on the randomized response mechanism [14]. Given a vocabulary V that contains all the possible keywords and a parameter p set by the user to tune the privacy level, the voice sanitizer executes the algorithm in the following steps. For each word w ∈ V: (1) Create a 2-bit array B = [b 1 , b 2 ] and initialize it to '00'. (2) If the user sets w as sensitive, then set b 1 to 1; otherwise set b 2 to 1. (3) For each bit i of B, set it to 1 with probability p 2 , set it to 0 with probability p 2 , or do not modify it with probability 1 − p. Let the new array we get be B . (4) Report w, B to the central server. We have the following theorem (see proof in Appendix A).
Theorem 1: PRAKA achieves 2 ln 2−p p -differential privacy. Since the user reports to the server only once for each w, the privacy level would not degrade over time. When the server collects enough reports from users, it estimates the frequency of each word set as sensitive by users. For each w, let N be the total number of reports, let n be the number of reports where bit 1 was set, the estimated number of users who really set b 1 = 1 is calculated byn = (n − p 2 N )/(1 − p). The error bound is given in Appendix B.
Randomized safeword selection: Given a safeword set, we split it into several subsets such that words within a subset are more similar to each other than words in another subset. For instance, a simple categorization is singular nouns, plural nouns, transitive verbs, intransitive verbs, adjectives, and adverbs. Each subset is a bucket of safewords. The categorization is pre-defined in the app. When the voice sanitizer spots an occurrence of a keyword, it randomly picks a safeword from the corresponding bucket to perform safeword substitution.

A. Emulation Setup
We run the emulation on three datasets. PDA: PDA is a speech database from CMU Sphinx Group [2], which contains 16 speakers each speaking over 50 short sentences. The number of female and male speakers are well balanced. They are all native English speakers, and 12 of them speak American English. LibriSpeech: LibriSpeech corpus is from OpenSLR [21], containing 100 hours speech, clearly read by 251 native speakers of American English without background noise. Volunteers: This dataset was collected by ourselves from 14 college students (11 males and 3 females). Thirteen of them are not native speakers and they have various accents from 9 countries. Their statistics are shown in Tab. I.
We utilize the Speaker Recognition API and the Bing Speech API from Microsoft Cognitive Services, which provides the state-of-the-art algorithms for spoken language processing [5], [35]. The steps of evaluation go as follows. First, we create a speaker recognition system and use the training set to train a voice model for every speaker in the three datasets. Second, we process the utterances in the test set using our voice sanitizer. We perform voice conversion differently for male and female speakers. Specifically, we deepen female voices (by setting α < 0) and sharpen male voices (by setting α > 0) to make their voices closer in pitch so as to increase the difficulty for the adversary in distinguishing different speakers (validated by experiment). Third, we use the trained voice models to identify the speakers of the sanitized utterances and evaluate the accuracy of speaker identification. Finally, we perform speech recognition on the sanitized utterances and evaluate the accuracy.
Metrics: We measure the performance of speech recognition using word accuracy, which is calculated by one minus word error rate (WER). The accuracy of speaker recognition is defined as the success rate, that is, the fraction of correctly identified speakers. By default, we measure the accuracy of identifying a speaker from a set of 50 candidates, but we also study the cases where there are much more candidates (Fig.  5). We measure the performance of keyword spotting using ROC curve, which illustrates the performance of a binary classifier system as its discrimination threshold is varied. The computation overhead of the voice sanitizer is measured by realtime coefficient, the ratio between the CPU time for processing the audio and the duration of the audio. processes by our voice sanitizer, but the extent of degradation with respect to a specific |α| is different for them. We can observe that in Fig. 4. Speakers can be correctly identified with a 100% chance when α = 0, i.e. on original utterances. Speech recognition on the original utterances achieves an accuracy > 80%. When voice conversion is applied with |α| ∈ [0.02, 0.10], the accuracy of speaker recognition degrades sharply with growing |α| while that of speech recognition is barely influenced. The huge gap provides us an opportunity to find a value range of |α| to overcome our key challenge, that is, to suppress the speaker recognition possibility while preserving the speech recognition utility. According to this figure, the proper range of |α| can be set to [0.08, 0.10].
That said, if we use only the bilinear function in the voice conversion for LibriSpeech and choose |α| from [0.08, 0.10], the accuracy of speaker recognition on the output speeches would be restricted within 0.20 but the speech recognition accuracy is still maintained at 0.72 ∼ 0.75. The results for PDA are even better: the speaker recognition accuracy is restricted to be smaller than 0.13 while the speech recognition accuracy is in 0.77 ∼ 0.81. The accuracy of speaker recognition is also partially up to the number of candidates from which the cloud identifies the target speaker, as shown in Fig. 5. However, if we do not apply voice conversion, the accuracy decreases extremely slow such that it is still 1 when we identify the speaker from 250 candidates. (We could not try more candidates because of the limit of dataset we obtained.) This figure shows that our method can reduce the speaker recognition accuracy by 90%.
2) Computational Cost: We record the CPU time of voice conversion on every utterance. The time of pitch marking and other 5 steps, and the total CPU time are all proportional to the duration of the utterance. Pitch marking is the most timeconsuming step. The realtime coefficient of voice conversion is 0.42 on average (Tab. II). We also find that the warping parameter α has little influence on the computational cost.
3) Emulation of Robust Voice Conversion: We have presented the idea of adopting a compound function h(ω, α, β) in Section IV-A, so now we try to find the proper range of α, β for this function. By Definition 1, the distortion strength of our compound function h(ω, α, β) can be estimated. Now the question is, what is the boundary of a proper distortion strength? As mentioned in Section V-B1, the proper range of |α| in the bilinear function f is [0.08, 0.10]. The corresponding distortions are dist f (0.08) = 0.32, dist f (0.10) = 0.40. So we adopt these two values as the boundary of a proper distortion: dist ∈ [0.32, 0.40]. Fig. 7(b) shows the proper range of α, β for h such that 0.32 ≤ dist h (α, β) ≤ 0.40. By randomly selecting α, β from this range every time we convert the voice of a speech, we can achieve our goal of impeding speaker recognition while preserving speech recognition, plus the goal of preventing the reducing voice conversion attack. An experiment on PDA demonstrates the efficacy of this technique, as presented in Fig. 6. The test on the unsanitized speech (dark blue bars) and weakly sanitized speech (green bars, bilinear function with α = 0.08) is also given as a contrast. After the speeches are perturbed by voice conversion with the compound warping function, the speech/speaker recognition accuracy decreases to 0.68 and 0.16 respectively, as indicated by the yellow bars. We can improve speech recognition accuracy by lowering the privacy level.

C. Emulation of Keyword Substitution
We evaluate the performance of our keyword substitution method on LibriSpeech. For every user, we constructed the keyword set by randomly choosing words from the transcripts and then manually labeled the occurrences of these words among all the speeches of this user. We apply our evolution based method to detect the keywords, and then compare the results with the labels. If the difference between detected start/end time and labeled time is smaller than 0.05s, this detection would be considered as correct.
As illustrated in Fig 8, without updating the keyword samples, the detection accuracy approximates to random guess. Our evolution based algorithm helps to improve such detecting accuracy to 90%, as indicated by the red line. To measure the computational cost, we assume there is one keyword per utterance. The most common case is zero or one keyword because most words in a sentence are insensitive at all. The realtime coefficient of substituting one keyword is 0.60, as shown in Tab   of keywords. With the development of keyword spotting, we can achieve better efficiency in the future.
Put it all together: We combine the two sanitization phases (keyword substitution and voice conversion) altogether and run the same experiment. The impact of speech sanitization on the accuracy of speech recognition and speaker recognition is presented in Fig. 9. Keyword substitution has a marginal impact on the performance of speech/speaker recognition. It is shown that we can reduce the risk of a speaker from being identified (given 20 candidates) from 100% to 16% at the cost of decreasing the speech recognition accuracy by 14.2%. The computation overhead of speech sanitization is given in Tab. II. The total real time coefficient is 1.02.

VI. DISCUSSION
Speech segmentation and randomization: There is an alternative to prevent the adversary from performing voice conversion on the speech reversely. The voice sanitizer executes speech segmentation and randomizes voice conversion on each segment. We observe by experiment that if a word or phrase is split into two halves and they are transformed to two different voices, they can hardly be recognized by the cloud. We can randomly partition the speech into segments with random size (segments are separated by the gaps between  words) and then independently convert the voice of each segment with randomly selected parameters. Compatibility with voice assistants: We aimed to protect the identity privacy of users of voice input and voice search. For voice assistant, some services activated by voice commands require authentication of the user (by other means, e.g. password, two-factor), e.g. creating an event on the calendar. The user's PII is inevitably exposed to the voice assistant, which appears to be against our goal. Today's voice assistants like Google Assistant usually works by three steps: speech recognition (voice input), command understanding, and command execution. The first step is not necessary for a voice assistant. We suggest it be decoupled from the voice assistant because users experience a higher privacy leak risk when all their data are stored at one single party. Instead, the voice input task can be taken on by a third-party dedicated to speech recognition and users connect to it through the voice sanitizer.
Assumption about PIIs: This paper assumed the cloud doesn't have users' PII, which can be achieved by existing widely deployed anonymous networks such as Tor [7], [8]. Yet at present, most of the speech recognition service providers have users' PII. However, our voice sanitizer still helps alleviate the risk of privacy breach. For one thing, every user's voice is converted to many different voices, which can reduce the chance that the user is recognized in real life. For another thing, the voice sanitizer hides the sensitive phrases in the speeches so it will be more difficult for the cloud to learn the speech content of the user.

VII. RELATED WORK
Security and privacy on voice data have been concentrated on in previous works from two main aspects. Spoofing attack to speaker verification systems has received considerable attention in the area of speaker recognition. The simplest methods are replay and human impersonation. More powerful techniques include speech synthesis [13] and voice conversion [34]. Meanwhile, many robust speaker verification techniques have been proposed to defend against those spoofing attacks [32], [33]. Other researchers [23], [24] proposed to use secure multi-party computation (SMC) to implement and achieve speaker verification in a privacy-preserving fashion. Smaragdis et al. [28] were the first to design an SMC-based secure speech recognition, though it is said to be a rudimentary system and the cryptographic protocols are computationally expensive. In addition, privacy learning has also been a focus in spoken language analysis. For example, Dan Gillick [17] showed that word use preference can be utilized to infer the speaker's demographics including gender, age, ethnicity, birth places and social-status. Mairesse et al. [19] designed classification, regression and ranking models to learn the Big Five personality traits of the speaker including "extraversion vs. introversion".
Other sensitive information contained in the utterance such as emotions [22] and health state [27] could also be inferred by speaker classification methods.
Another related work by us [26] studied and quantified the privacy risks in speech data publishing and proposed privacypreserving countermeasures. By the way, there is a body of work on distributed speech recognition e.g. [36] for mobile devices. It enables the device itself to extract spectral features from the speech and then send them to the cloud where the features are converted to text. Distributed speech recognition is not commonly used yet and the main purpose is to reduce the communication cost. Though the user's voice is not directly exposed, still the features like MFCC can be used to extract voice print and reconstruct the voice accurately.

VIII. CONCLUSION
Now we are speeding toward a not-too-distant future when we can perform human-computer interaction using solely our voice. In this work, we present a light-weight voice sanitization app that achieves a good protection of both user identity and private speech content, with minimal degradation in the quality of speech recognition. Our system adopts a carefully designed voice conversion mechanism that is robust to several attacks. Meanwhile, it utilizes an evolution-based keyword substitution technique to sanitize the voice input content. Possible future work includes explicitly defining identity privacy for voice input users and achieving adaptive speech recognition while preserving identity privacy.

APPENDIX A PROOF OF THEOREM 1
Proof: This proof is inspired by [16]. Let B = [b 1 , b 2 ] be the new Bloom filter we get after Step 3 of PRAKA. For any i = 1, 2, we have For any two distinct values of B, say B 1 = [0, 1] and B 2 = [1, 0] without loss of generality,