Agreed, but I'm not convinced that a weak FM signal isn't just some electronic artifact of a crap board crammed in with a bunch of other tiny components that happens to be triggered when the microphone is on.
It seems unlikely that the flaw was intentional - there are much better ways of leaking audio that are much more difficult to detect. But it's interesting that the design and the cheap components or whatever have all conspired to leak the audio in FM.
If nothing else, it's a great lesson in how security is just a very difficult subject, and 'secure' an almost nirvana-like state in terms of the impossibility of achievement.
Yep I'd definitely chalk this down to being unintentional myself. I'd guess that there's leakage from the ADC on the mic which won't likely ever be turned off since clock gating it would be difficult (many of those guys talk on SPI or I2S or some such, which doesn't make that easy) and gating the power could have all kinds of noise issues during power on and off. Why it's that easy to pick up and why around 24mhz i'm not sure myself.
My best guess is that your sound is stimulating some capacitor connected to a voltage-controlled clock oscillator in the laptop. The voltage provides by the sound is causing the frequency of the VCO to move around slightly. 24M is a pretty common frequency in electronics for use as a general-purpose digital clock.
I concur. If another laptop of the same model doesn't show the problem, that points to a manufacturing defect.
It can be easy to route noise through an area the designer didn't intend with a simple solder blob or a defective power supply bypass capacitor. 24MHz could just be a frequency of a crystal oscillator.
I'd want to know the actual power level of the transmission, but to measure that accurately, you'd want to put the laptop in a shielded chamber.
As an example component, here's a SPI mux by Maxim that has 8 separately-controlled SPST switches for <= $3.30 (probably much cheaper at scale). http://www.maximintegrated.com/datasheet/index.mvp/id/1281 So, if you utilize this fully, you could clock-gate 8 separate SPI components for < $0.42 each, right?
Is a mux the wrong way to do it? What's the proper implementation?
Nothing. SPI and I2S is usually not implemented with free-running clocks anyway, the clock only runs when there's data on the interface. Sorry, grandparent.
I think what the parent was referring to was that a lazy circuit designer might just never power off the mic, in order to avoid the characteristic "pop" sound associated with older audio equipment.
That'd gate the clock on the bus talking to the digital components, but there is also going to be a separate clock that the ADC will be using to keep track of sampling with less clock jitter. If you start gating that clock off you can end up with some unpredictable results when you start to read back after you turn it back on (unless the IC was built to expect it). This would all have to happen outside of SPI or I2S, which means more hardware and more cost, and probably a more expensive ADC. None of the ones I've seen (been wanting to play with a few) explicitly support doing that because they've got a clock multiplier internally that they use.
The MUX you link to would likely allow them to disconnect the microphone easily, BUT it wouldn't prevent the noise on it's own in the first place. There'd likely still be a signal at 24MHZ that shows just blank audio, it'd be better for security of course but doesn't fix the leakage.
Typically, a converter is fed (or generates internally) a few clocks at multiples of the base sample rate. Depending on the CODEC the highest clock could be 256baseFS or even 512baseFS. At a common rate of 48kHz (which cleanly divides samples into both 30fps and 8kHz USB uFrames) this ends up at 24.576MHz.
Keeping the clocks running makes it easier to start streaming audio. Otherwise, restarting the clocks means you have to wait for them to settle before pulling the ADC out of reset. After that you have to flush buffers, align samples for phase/latency, and artificially zero the input stream until the rest of the circuitry settles down. Keeping the clocks running means turning the input on or off is only a matter of passing the audio samples or passing zeros.
Also, if the system isn't grounded properly then the analog input could definitely find its way onto the 24.576MHz MClk. In the audio world, digital noise leaking into the audio stream is universally bad while no one usually bats an eye at analog leaking into the digital domain.
It's definitely lazy from a security standpoint but probably not intentional.
My roomate was just issued one of these "laptops." They weigh a ton, the keyboard doesn't work worth a damn, the trackpad is all but useless, and the wifi is flakey -- and it's brand new. Judging from its build quality, it's completely unintentional that this kind of leak was possible.
It's obviously completely intentional that the laptop be put together with less aplomb than a speak 'n spell.
19 comments
[ 7.6 ms ] story [ 49.7 ms ] threadIf nothing else, it's a great lesson in how security is just a very difficult subject, and 'secure' an almost nirvana-like state in terms of the impossibility of achievement.
It can be easy to route noise through an area the designer didn't intend with a simple solder blob or a defective power supply bypass capacitor. 24MHz could just be a frequency of a crystal oscillator.
I'd want to know the actual power level of the transmission, but to measure that accurately, you'd want to put the laptop in a shielded chamber.
What makes clock gating of SPI & I2S difficult?
As an example component, here's a SPI mux by Maxim that has 8 separately-controlled SPST switches for <= $3.30 (probably much cheaper at scale). http://www.maximintegrated.com/datasheet/index.mvp/id/1281 So, if you utilize this fully, you could clock-gate 8 separate SPI components for < $0.42 each, right?
Is a mux the wrong way to do it? What's the proper implementation?
The MUX you link to would likely allow them to disconnect the microphone easily, BUT it wouldn't prevent the noise on it's own in the first place. There'd likely still be a signal at 24MHZ that shows just blank audio, it'd be better for security of course but doesn't fix the leakage.
Keeping the clocks running makes it easier to start streaming audio. Otherwise, restarting the clocks means you have to wait for them to settle before pulling the ADC out of reset. After that you have to flush buffers, align samples for phase/latency, and artificially zero the input stream until the rest of the circuitry settles down. Keeping the clocks running means turning the input on or off is only a matter of passing the audio samples or passing zeros.
Also, if the system isn't grounded properly then the analog input could definitely find its way onto the 24.576MHz MClk. In the audio world, digital noise leaking into the audio stream is universally bad while no one usually bats an eye at analog leaking into the digital domain.
It's definitely lazy from a security standpoint but probably not intentional.
It's obviously completely intentional that the laptop be put together with less aplomb than a speak 'n spell.
Sounds like every HP consumer product I have ever seen or used, especially laptops.
Now, if only there were some gov't agency that could regulate the emissions standards for electronic devices sold in the US. /sarcasm
Thanks for the link.
Learn your electronics and don't believe in rumors ;)