Schneier on Security

Clive Robinson • July 20, 2010 3:45 AM

@ Robert,

“However what is missing from this axiom is that the clock must be guaranteed stable at 1/10 information density of the application to be properly protected.”

True(ish) for a side channel that leaks data accidently (but I would put the divide rate higher, and as we are talking voice and possibly just phonem envolopes at 3 or 4 a second so we are looking at milli Hz stability.

With a covert channel it depends on the infomation density that the “attacker is trying to leak and that could be just a master key at one or two bits a minute (the majority of voice calls don’t need to be monitored in real time more than 99% of them not even within an hour…) Usually the routing information is more urgent than the content.

All of which means the old axiom of clock the inputs and clock the outputs only works so far.

Another two axioms that help are “fail hard” and “fail long”. That is on any timing error assume it’s a covert channel and close both the communications signal and control channels. Don’t ever try and correct any timing error as this as you noted gives rise to an external attack.

Importantly don’t try and re-establish coms for a long period which needs to be atleast semi-random in duration. It should also be known what this back off duration is to both ends to remove another covert channel issue.

Now I know that Skype is not going to do either of those simply because it negativly impacts the users view of the quality of the service.

Another EmSec axiom people realy realy should remember is “data should be constant in all channels”.

For instance if you use compression it gives away the envolope of voice comms which some older musicians may remember is all a vocoder uses to make a violin not just weep but talk as well 😉

Therefore you have to rate stuff back to a higher data rate, and again you have to be very carefull how you do that. Simply because it’s fraut with side channels not just in the comms signal channel but in the control channel as well (no point taking the envelope out of the signal channel if your “data stuffing” “signalling method” reproduces it in the comms control channel).

Which for side channels implies as you say,

“For properly protecting voice this implies a very stable source, with vibration and temp protection = very expensive (test instrument quality clock)”

Which is effectivly impractical to do even with modern mobile phone Xtals.

However it’s worse, it cannot be done for covert channels as I said they might leak data at millibit rates.

The solution to this is to deliberatly introduce “jitter” into the system effectivly you spread spectrum modulate the clocking in and clocking out clock at a rate just below the bottom of the audio band. The spreading code needs however to be highly nonlinear and known to both ends of the channel. This then effectivly encrypts any low bandwidth timing based covert channel to an external entity. It also has other advantages as the CCITT have shown for years with “channel whitening” with short LFBS’s to spread the energy across the channel bandwidth.

Oh and this clocking in clocking out and spreader needs to be fully independent of anything else…

It also has another use in that it shows if either party is moving and if somebody is trying to time remodulate the signal post output clocking etc …

Oh and of course there are other wrinkles that need to be ironed out as I often say “the devil is in the details” >;}