Subject: [AVT] Comments on draft-perkins-avt-srtp-vbr-audio

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 16 Nov 2010 13:17:22 +0100

Hi

I have now re-read both the draft as well as the paper and my impression is that the draft is good to have as an informational to inform people about a possible issue, therefore I support it.

Today it may be quite far fetched to imagine that much useful information can be extracted this way (I even have problems to get our automated speech recognition exchange understand me...). 
However, anyone who has read a spy novel by Tom Clancy or John le Carré realize that eavesdropping is more or less picking fragments of information from many different sources (including trash-bins). This in combination with Moores law says that implementors should be aware of this issue.

Section 4: My personal feeling is that the recommendations are too far, the idea is that an eavesdropper can extract information from the length of the talk spurts. This to me sounds like a much more difficult task than the VBR case (which is difficult already that). A hangover of e.g 1s is very likely to give 100% activity time for speakers of a particular south-european nationality :-)

Section 5: A variation to the padding is to randomly pad a fraction of the packets up to a large size (less or equal to the largest packet size from the codec) than , this, I believe should confuse the eavesdropper algorithm considerably. It is possible that the same can be applied to VAD case in section 4 as well.

/Ingemar 

=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 16 Nov 2010 13:52:44 -0500

Hi Ingemar,

On 10-11-16 07:17 AM, Ingemar Johansson S wrote:
> Today it may be quite far fetched to imagine that much useful
> information can be extracted this way (I even have problems to get our
> automated speech recognition exchange understand me...). However, anyone
> who has read a spy novel by Tom Clancy or John le Carré realize that
> eavesdropping is more or less picking fragments of information from many
> different sources (including trash-bins). This in combination with
> Moores law says that implementors should be aware of this issue.

I think you've pretty much summed up the idea we were trying to convey. 
Conversational speech recognition is indeed hard enough when we have the 
audio that recognizing from VBR is quite far-fetched unless the vocabulary 
is highly constrained.

On the other hand, the real worry I have with VBR and VAD is for 
pre-recorded prompts like you have in an IVR. If an attacker knows the IVR 
prompts (e.g. has an account at the same bank as you), then they can 
extract patterns that are very precise and obtain 100% identification on 
the known prompts. This is the case even with the counter-measures 
described in the draft. On the other hand, anything that isn't pre-recorded 
is not something that worries me too much.

> Section 4: My personal feeling is that the recommendations are too far,
> the idea is that an eavesdropper can extract information from the length
> of the talk spurts. This to me sounds like a much more difficult task
> than the VBR case (which is difficult already that). A hangover of e.g
> 1s is very likely to give 100% activity time for speakers of a
> particular south-european nationality :-)

Any suggestion for a reasonable the hangover half-life?

> Section 5: A variation to the padding is to randomly pad a fraction of
> the packets up to a large size (less or equal to the largest packet size
> from the codec) than , this, I believe should confuse the eavesdropper
> algorithm considerably. It is possible that the same can be applied to
> VAD case in section 4 as well.

I'm not sure what you are suggesting. I think VAD is a bit different from 
VBR because it's a binary decision. If you decide not to send a packet 
based on the VAD data, then you can't just do padding. Similarly, if the 
VAD triggers a low-rate mode, then the padding would have to be high enough 
to make the packets indistinguishable from high-rate mode, which means it 
acts as an overhang. Or maybe I didn't quite understandand what you were 
suggesting.

Cheers,

     Jean-Marc

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 17 Nov 2010 08:45:02 +0100

Hi

Answers inline below

/Ingemar 

> -----Original Message-----
> From: Jean-Marc Valin [mailto:[email-masked]] 
> Sent: den 16 november 2010 19:53
> To: Ingemar Johansson S
> Cc: [email-masked]; Colin Perkins
> Subject: Re: Comments on draft-perkins-avt-srtp-vbr-audio
> 
> Hi Ingemar,
> 
> > automated speech recognition exchange understand me...). However, 
> > anyone who has read a spy novel by Tom Clancy or John le 
> Carré realize 
> > that eavesdropping is more or less picking fragments of information 
> > from many different sources (including trash-bins). This in 
> > combination with Moores law says that implementors should 
> be aware of this issue.
> 
> Conversational speech recognition is indeed hard enough when 
> we have the audio that recognizing from VBR is quite 
> far-fetched unless the vocabulary is highly constrained.
> 
> On the other hand, the real worry I have with VBR and VAD is 
> for pre-recorded prompts like you have in an IVR. If an 
> attacker knows the IVR prompts (e.g. has an account at the 
> same bank as you), then they can extract patterns that are 
> very precise and obtain 100% identification on the known 
> prompts. This is the case even with the counter-measures 
> described in the draft. On the other hand, anything that 
> isn't pre-recorded is not something that worries me too much.
Then I would say that a general recommendation is to always use padding for VBR or turn off DTX in the case you describe above. This should be a very small amount of the total traffic volume so one don't need to worry about increased network load.
How is the padding for the VBR case negotiated ?. I guess you don't intend to negotiate this or ?, DTX can be turned off but the padding is not possible to negotiate today

> 
> > Section 4: My personal feeling is that the recommendations are too 
> > far, the idea is that an eavesdropper can extract 
> information from the 
> > length of the talk spurts. This to me sounds like a much more 
> > difficult task than the VBR case (which is difficult 
> already that). A 
> > hangover of e.g 1s is very likely to give 100% activity time for 
> > speakers of a particular south-european nationality :-)
> 
I would actually prefer no extra hangover other than that already inherent in the codec. This is more due to (imagined) network load reasons than security reasons however as I believe the security concerns are not that severe. If we think secuity then why not just recommend to turn off DTX completely for very sensitive applications ?.  A 1s overhang will IMHO drive the voice activity factor so high so one may aswell turn off DTX completely .

> > the packets up to a large size (less or equal to the largest packet 
> > size from the codec) than , this, I believe should confuse the 
> > eavesdropper algorithm considerably. It is possible that 
> the same can 
> > be applied to VAD case in section 4 as well.
> 
> I'm not sure what you are suggesting. I think VAD is a bit 
> different from VBR because it's a binary decision. If you 
> decide not to send a packet based on the VAD data, then you 
> can't just do padding. Similarly, if the VAD triggers a 
> low-rate mode, then the padding would have to be high enough 
> to make the packets indistinguishable from high-rate mode, 
> which means it acts as an overhang. Or maybe I didn't quite 
> understandand what you were suggesting.
Hmm, you are right (brain fart). I was thinking like for instance an AMR case where you can actually transmit frames of type NO_DATA after the SID_FIRST frame but unless you make it an overhang (like you already suggested) you still get "holes" which are easily detected by the eavesdropper.