Schneier on Security

Clive Robinson • March 9, 2012 4:05 AM

@ RobertT, Nick P,

Robert with,

, In theory these military radios are great performers in practice they suck, so we have the equally silly case of deployed troops communicating during an operation using iPhones and some commercia conference call facility

“thud” you have squarely hit the nail on the head…

Back in the 1980’s I was involved with a project for a military development agency that was looking at using the original Motorola Cell phone system with Racal UK developed enhancments as a “fly in and use” system to replace combat radio systems that were a mess back then (remember the Falklands War and later 1st Gulf War).

The system worked like a dream in comparison to what was around, one big Racal enhancment was the ability to locate by triangulation the position of a user with greater accuracy than the then GPS (civilian + SA). Another Racal enhancment done with BT Martalsham was the abbility to send 9600baud data reliably and 2400baud at fixed rate across cell swaping thus alowing the voice encryptors developed by the likes of Plesey to work very reliably (unlike the high HF / low VHF equipment that predated the almost as bad Clansman Kit).

What killed it all of was Motorola who refused to alow it to be used as they saw it as compeating with their Trunked Radio System (now called TETRA which was and still is a complete disaster for UK and many other civil authorities).

The result was Motorola lost out twice instead of winning twice and the UK troops ended up with Clansman and a godam awful trunked system that fell over so often the word “trunk” was replaced by “drunk” by not just the army technicians who had to work on it but the manufactures design engineers and technicians as well. Oh and then there was Mould, but best not go there, there may be a few UK amateur radio boffs reading who would like to vent their spleans against that piece of stupidity.

But it gets worse from what I’m told the replacment system used in the current Afghan and Iraq actions is not much better and this has had two consequences,

Firstly the old Clansman kit that had been in the process of being scrapped and sold off has been “bought back” at considerable expense and secondly as you noted the likes of the iPhone are being used with commercial services.

It is interesting to note that the US military hierarchy appear to be “embracing the iPhone” and also that Apple are in the process of building a new manufacturing plant in Texas.

The question is why…

Likely answers are,

1, to avoid “import restriction” battles that have kicked off over IP in phones as Microsoft Apple and Motorola abely assissted by the likes of HTC and Samsung. have demonstrated in recent times.

2, To develop an “out of China” production facility to stop the ripoffs of Apple products have suffered over there (take serious note other manufacttures thinking of going down the “cheap China” route it could cost you way more than you save).

3, To develop the first steps of a “secure product” line in the US for the benifit of the US politico’s, military and major corps as an alternative to RIM products.

Or some combination of the above and/or other reasons not yet identified.

All of that aside “Military Radio” systems are a dead concept these days, they take to long to develop they are way way to expensive and their functionality even with the best will in the world is usually way below that of PMR or other comercial offerings. The military thinking has moved on from “single channel nets” with all the problems that involves to “dial direct” and “tele-conferancing”. On the wish list of most troops is a rugadised iPhone with a slot in so they can whack in their smart card ID with it’s PKI and go straight into secure mode with a change of screen colour etc, take it out and be back in civilian mode. Simple to understand and low stress not real thinking involved and importantly relativly easy to do and have use of COTS advantages.

Will it happen, well it should, and it should not be that difficult to do but… I’m not holding my breath there is way to much vested intrest in “old slow and mega expensive” by the current encumbrants, and we know from experiance they will cut their nose of to spite their face.

Clive Robinson • March 11, 2012 9:52 AM

@ Jake, Sweerek,

TPM is no magic bullet, it is still vulnerable to cold boot attacks and the only real barrier it provides is accessibility to keys via the hardware

Err actually TPM is a fully busted flush for security, and serves only minimal purpose for DRM.

The problem is TPM sits quite a way up the computing stack and is closer to the application layer than the fundemental physics of the underlying hardware.

Thus for TPM to work the hardware has to be 100% trusted in all places and in all ways, the only ways know to get even vaguely close are so grossly inefficient and eye wateringly expensive that they will not happen outside of very very specialist devices.

But plain and simple we know that it is not possible for a single Turing machine to be secure, the best we can hope for is “probabalisticaly secure” and we actually had the knowledge of this prior to the first electronic computers ever being built.

The interesting thing about “probabilistic security” is it’s a “trade off” between time spent on achieving a desired task and checking it has not become rouge in some way. Thus you can trade security against efficiency in the right architecture.

Clive Robinson • March 12, 2012 8:55 AM

@ RobertT,

These channels only need to leak at bits-per-second to transfer the session encryption keys

Not even that high a data rate if all the keys are derived from a hidden unchanging master key, a bit or two a day would do, especially if the master key was not truly randomly generated (ie the SIM manufacture uses AES in CTR mode to generate a few bits that get put in the SIM and the phones electronic serial number a few more etc).

The problem is you are effectivly “black box testing” quite a way up the stack (ie chip level to App not chip level down to physics level) which gives rise to your question of,

Who is going to identify, let alone check, all the possible side channel information leak methods?

Well… this falls to the “Known knowns”, “Known unknowns”, “Unknown knowns” and “Unknown Unknowns” problem defined by classes of attack and specific methods within a class.

Known knowns, should not be to much of an issue if they are detectable which unfortunatly not all are with a black box system (the same problem as identifing if a random looking stream of bits is truely random or determanistic)

Known unknowns, are new varients within a “class” of attacks. That is if you identify a basic class of attack (say a timing attack based on adding jitter to the data TX sequence) then finding a generic solution to that attack (clock the outputs) solves the problem for the whole class within known bounds.

Unknown knowns, are specific types of attack known in one domain (class or channel) that are moved into another domain. For instance spread spectrum modulation can be applied to the carrier channel (RF signal) by modulating it’s amplitude, frequency, phase and sequence (if SS it’s self). But as was seen with watermarking it could also hide a covert channel in the data channel as normal data has it’s own noise to hide in. As a general case as with known unknowns you can apply a generic mitigation, but it has to be in each applicable class and you may not know all the classes or how to come up with a mitigation. For instance amplitude modulation can be mitigated (in part) by some kind of limiting circuit, but frequency modulation has to be mitigated in an entirely different way.

Unknown Unknowns, these are basicaly unknow vectors in unknown domains, generaly the only way to find these is by carefull examination of energy signals in all the basic channels (carrier, modulation, timing, data, meta data, meta meta data etc etc). Of course you have to be able to identify all the basic channels and that may not be possible, and likewise the energy signiture.

Then there is the question of “transparency” whilst you might be able to mitigate some covert channels in a domain it may not be possible to eliminate them all and still have a functioning system. Take “clocking the output” that has two limitations that can easily be seen, firstly it is effectivly frequency dependent in that data rates below the basic data rate can get through and secondly any channels within the data etc get through. As an example any system leaks one bit of data unavoidably, that is it is either in operation or it is not, and this applies at all channel levels within the system. So one technique might be to generate a covert channel in the error correction mechanism of a block within the system.

Thus if the input to a block within the system was delayed deliberatly then clocking the output would require a pause or re-sync before transmittion could continue. And the pause / re-sync provides the covert channel.

The usuall solution to this is to clock the “input” from a master clock. That is you pipeline all the system blocks together as a fully synchronus system. Unfortunatly this also has limitations and an even slower covert channel can still be formed by simply stoping and starting data transmission into the first block of a system.

The solution to this are two fold, firstly fail hard on errors and back of on retransmission a very long random amount of delay (but this only goes so far). The second is to “store and forward randomly” that is all data input to the system is stored and then sent randomly out of sequence be it as whole “messages” or “fractions of messages” providing the sellection process is not determanistic and the system can reassemble fractions correctly you will disrupt the covert channel in the error system. Effectivly what you are doing is taking the covert channel and randomly modulating it. However after all of this there will still be a very low bandwidth channel you cannot stop (ie system on or system off).

With regards your comment,

My gut feeling is that it is only even thinkable if you limit the Android device to executing one active program and nothing else

No this does not work, it just lowers the oportunity.

Think of the transparency and store and forward issues. If a rouge app runs at some point it can load up it’s chosen “covert channel” with data which will just sit there. At some point a non rouge app will establish communications, as long as the data stored by the rouge app gets used the covert channel is established and the leaked data forwarded.

For instance let us say the rouge app is an off line email client it can establish a meta meta data covert channel by the use/abuse of standard headers in individual messages it puts into the spool directory/file. When the mail transfer agent sends the Emails in the spool it is passivly and unknowingly establishing the covert channel and sending data down it.

This workes well because many headers are effectivly redundant for any given message (think 7/8 bit data identifier or extended charecter set identifier, most systems will process the Email correctly even it the identifier is not included, and will ignore a set identifier if it is included but not necessary).

And at the end of the day the real issue is, any system that has some form of redundancy in it can have a covert channel tucked away somewhere. However without redundancy the system could not function… thus “Catch 22”.