Schneier on Security

Clive Robinson • May 28, 2010 12:07 AM

@ Robert,

“Seems easier to focus on a dedicated piece of hardware…”

Simple answer is it is…

Also there is an issue with formal proofs called either axioms or assumptions (take your terminology choice as they both essentialy mean the same).

A clasic example of this occured just the other day (I’m surprised Bruce has not bloged about it HINT HINT)

Basicaly a group of bods over at the University of Toronto have broken a comercial Quantum Key Distrubution (QKD) device that is “theoreticaly 100% secure”.

They did this by “re-visiting” the assumptions in the formal proof about error rate levels (the 20% margin) and realised the formal proof only acounted for natural noise not error noise at the originator (Alice).

They then found a way for Eve to exploit this ommision and stay at 19.7% error rate, thus Alice and Bob seeing a less than 20% margin assume (incorectly) they are 100% secure because that’s what the proof says….

To avoid the usual commercial out cry they went ahead and demonstrated the break on a piece of commercial quantem cryptography equipment.

You can read more on arXiv where a copy of the paper is.

http://uk.arxiv.org/abs/1005.2376

And download a PDF of their paper.

Clive Robinson • May 28, 2010 6:42 AM

@ Robert,

“Key exchange: needs some work.”

I think that qualifies as the understatment of the century possably the millenia 😉

Much as I hate to say it, it may turn out to be an unsolvable issue due to three issues,

1, Trust.
2, Distance.
3, Authentication.

We know from experiance that hierarchical systems reduce steadily to a single point of failure the closer you get to the top. And likewise the closer you get to the top the higher the rewards for betraying the trust in the hierarchie.

Worse the closer to the top you subvert the system not only the more damage you can inflict but the easier it is to hide.

So from a security asspect hierarchical systems are a compleate non starter as the risks are way way to high.

Non hierarchical systems usually revolve around a web of trust and surprisingly the majority of people are connected by very sort chains of no more than six entities. So in theory a world wide trust net could be fairly easily established.

Sadly there are problems with webs of trust, most people do not trust a chain of more than one “non known” link, thus we had key signing parties where people would turn up with “authenticating” paperwork such as a passport and get their key signed by a verifier who acted like a notary public.

Even this had problems in that it was locality based, that is the verifier was only trusted local to them and the distance issue could not be resolved. There also arose the issue of cross boarder juresdiction issues and legal liability.

Also was the problem of authentication paperwork, or how does the verifier know the document they are looking at is genuine, and how do you know that the verifier is genuine…

You have two choices, the first is use a bureaucratic hierarchical system (passports) that are known to be easily subvertable, the second is you take a chance via multiple verifications, that is you take a passport a bank statment a local government land tax statment utillity statments drivers licences school certificates etc etc. None of which are incapable of being forged, but using so many independant hierarchies that subverting them all would be difficult.

The problem is that none of them is independant they are all usually traceable back to a single root document called your Birth Certificate.

And the joy or curse (depending on your view) of a birth certificate is it is not atributable to any individual… That is it is a piece of paper that makes a claim as to an event (ie a birth) and nothing else, it is not tied in any way to an individual…

So as you can see Key Verification is currently impossible to do in any meaningfull way, and any system that attempted to do it would have to address the trust issue in hierarchies, which appears to be impossible to solve.

Then just to make it all doubly fun there are “entity roles” to consider.

As an individual you have many roles in life that are and should properly be separate. That is my personal financial affairs should not be linkable to a companies financial affairs or those of any clubs or societies etc I might manage. The less executive the role the less linkage there should be on roles. For instance if I was just an accounts clerk in a large multinational organisation that commits trading or other fraud, is it fair that I be judged non judicialy just by association?

The answer of course (if you believe in innocent untill proven guilty) is no.

However humans are increadably bad at not intermixing their roles in life, imagine how you as an individual would manage between twenty and fifty roles and the associated keys that went with them…

As Bruce has pointed out on more than one occasion, effective crypto algorithms is now effectivly a solved problem, it’s time we got on with the more difficult problems such as system design and key managment…

Clive Robinson • May 29, 2010 2:38 AM

@ Nick P,

Just to be different I will answer your post kind of in reverse and a bit at a time.

“I know you love your prisons concept but it’s to radical for this.”

Oddly your description of your two CPU hardward was almost exactly where I started which gave rise to the prison idea (now people are going to say something 😉

So some history first,

{–

The idea originally was to “make a better mouse trap” kernel to get rid of the inefficiency of having the whole kernal on each CPU in a multi CPU system (back then even micro kernals weighed in at more than 80% of memory on the most high end of single chip embedded CPUs something that has only changed in the past few years).

And further to significantly improve the “real time” response of a multi CPU embedded system where each embedded CPU was for controlling real time IO sensors and actuators (think about a CAN bus system on steroids as a starting view point for a SCADA or process control like system).

That is to seperate what the user process side required from what the system side required. In essence a seperation kernel at the hardware level (so the ideas are conceptually the same).

This was originaly for “programer efficiency” as well as hardware efficiency and real time response security was not even a consideration originally.

The realisation that bucket loads of security could actually come for free with a (very) reduced to minimal code in the user process area was nice. You need to remember that security is at best an after thought in most embedded systems, an over sight we are starting to pay dearly for (in the past there was the reasonable excuse of limited resources, this just does not apply any more and the exuse has moved to that of programer costs…)

Likewise in turn the “all IO and control is a stream” viewpoint to make programers more efficient also gave further minimisation and again increased security for free by side / covert channel reduction.

It was this “security for free” that made me curious as to just how far you could go getting improved efficiency (programer and hardware) but with “stealth security” in mind.

The reason for “stealth security” is simple as you probably know security is an almost impossible sell to a standard embedded code shop, however improved programer efficiency is a very easy sale, likewise reducing hardware costs. So getting the buy in for improved security was hidden behind the cash in of efficiency (hey sometimes you have to pull the wool over their eyes for their own good 😉

When you put the bulk of the kernel (system side) onto a seperate processor the first thing that happens is that malicious code has a real hard time getting a toe hold let alone getting at other “sensitive information”. And further by the old “clock the inputs and clock the outputs” of the user IO making covert channel bandwidth very small (which is again conceptually the same as the SK approach).

There is also an added bonus you can control the user CPU concept of passing time simply by stoping it’s clock to put it in “zero power mode” malicious code would be unable to use “jitter” for a covert channel as it would have no time refrence in common with it’s external receiver (something the SK does not yet do as well but it,s getting there).

Thus by a number of tricks you can reduce the covert channel “jitter” bandwidth to sub millihertz bandwidth without effecting system performance by more than a few percent. (Something the SK approach will have great difficulty doing in it’s current forms)

To see how you might do this look at how two high refrence frequency PLLs can be combind to give fractional hertz frequency steps, there’s several different was such as using phase accumulators or having the two PLL refrence frequencies differ by the required frequency step or the delta sigma loop.

As time moved on the “PC revolution” caused the cost of high end CPU’s and memory to tumble in comparison to embedded CPU’s (look at the real cost differential on silicon real estate and it will take a week for your eyes to close again after the shock)

Thus I started looking at more general purpose computing platforms for much higher performance at the same cost point. A further simple realisation of what two CPU architecture could realy offer hit me right between the eyes.

For instance turning the user process CPU MMU control bus over to the kernal CPU became a real eye opener, it effectivly turned the user CPU into a “walled Garden” within the confines of a much larger “memory” estate. I simply followed the reasoning and changed a few other things to actually reduce the tranistor count.

The real security bonus is you give the user CPU only the memory required to do it’s job, thus having no memory “slack space” (this is still a bit of a problem in the SK in that processess get the same resources by default, not an ammount tailored to the process needs which can mean a lot of slack space).

With little or no memory slack space malicious code then has insufficient space to hide and there is a wonderful non linear problem that works in the system security favour. As you break a complex task down into smaller functional blocks the amount of memory required goes down and slack space easier to eliminate. However the job of adding extra malicious code gets exponentialy more difficult for the attacker…

Then the thought about a security hypervisor to actually go “inspect the memory” to check for “unexpected code” comes naturaly hence moving from the “walled garden” analogy to that of a “prison”. Which then gives a different view point yet again and further insight on how to get other advantages.

–}

So yes the two CPU deign puts you on the top of that slippery slope 8)

I know that anything I do in a hardware prison approach can be emulated in software by an SK

The real question is not which approach (SK or prison) is conceptualy better (as the gap is closing) but the real cost difference.

Over the system lifetime some things in hardware are very very cheap and very very expensive in software, but the initial cost skews the viewpoint in the oposit direction by a long way.

There are issues with an SK one a single CPU, that cannot arise on a multi CPU prison approach, one of which is the reliability of “formal proofs” because of the assumptions they are founded on (see my above post to Robert on the issue that has just arisen with Quantum Key Distribution).

I’ve seen many many “software security proofs” fail in my life and almost always it’s due to incorect assumptions. Being software you cannot see the failing easily. With hardware however you can see what is going on and much much more reliably control it.

Sometimes the real cost of a system is hidden, that is the “clean up cost” or when it goes wrong how much is it going to cost to clean up the mess.

A news worthy example is the problem PB has currently got with it’s deep sea oil well.

I used to work in the oil industry designing safety critical systems such as “red shutdown” these systems are increadibly expensive to implement and can add a hugh cost margin to an off shore platform. They are almost never used so there is always the temptation to cut costs on them. For very sound reasons they used to be almost always hardware not software solutions.

I think at the end of the day the problem BP had was one due to cost minimisation and on the day the system realy was required it failed and at the root of it will be an incorrect assumption.

I do not know what the clean up cost in dollars and cents will be but the economic knock on effect to the man on the street may well be comparable to that of the collapse of the banking sector…

It is this sort of hidden cost that the likes of the NSA has to deal with upfront and they cannot afford to get it wrong as the cost will be not just monetary

Hence the very conservative design approach.

Clive Robinson • June 4, 2010 12:57 AM

@ Robert,

“Actually voice security is a very hard problem…”

and them some 😉

One of the “ping pong” arguments myself and Nick P have is to the way you go about segregation.

I don’t belive for many of the reasons you state that it is actually possible to have a verifiably secure system with only a single CPU.

Thus two or more general purpose CPU cores and a state machine hypervisor that controls the limited bandwidth channel between the two.

Having worked with (and actually have sitting infront of me right now) Motorolas quad band GPRS java modules (G24) I’m aware of not just the GPRS issue but…. Motorla holds the signing keys in Israel.

With regards the supply chain i’ts an issue I have banged on about in the past both on this blog and over at the Cambridge labs blog “lightbluetouchpaper”. The example I usually quote is that of Apple shipping “pods” with virus code for PC’s on them…

As for your “final thought” I don’t know which particular company you refer to but I can confirm first hand that such behaviour does go on.

If you want to see how some real nasty things can be done have a look at Adam Young and Moti yung’s work on cryptovirology and backdooring RSA signatures.

In essence there is more redundancy in the number of prime pairs than you would like. Thus it is possible to put an invisable backdoor into the upper half of the pq product that will give you an indicator as to what p or q are and thus short circuit the factorisation security…

I actually wrote some code to do this in a covert way and got it through a quite serious code review process without it being noticed or even queried…

The way I did this was the old unalocate realocate buffer space without clearing the buffer trick. That is I did not clear the old buffer before freeing it or clear the new buffer onced malloced. I then used a secondary XOR trick to appear to be overwriting the data whilst actually keeping it. And to hide the fact that I was upto dirty tricks I used the PQ pair in the BBS random number generator to sign the search starting point for the new P…

Other tricks I have used in the past are using pointers to functions stored in a table… Once you know where the table is either using the functions out of order or illicitly becomes oh so easy. Thus knowing this you write the functions in a way that is most conveniant to you.

The nice thing about the BBS random number generator is, it effectivly has a public key built into it which you can use to encrypt information. As you generate this PQ pair for the BBS gen and embedd it in the code you can backdoor any of the bits you chose. Thus you can have a short PQ pair hidden in a larger PQ pair so that you can use the short PQ pair to encrypte say one sixth of the bits of the new PQ pair you are generating for the end users new public key. This shortish block of bits is an encryption of a simple truncation of the upper part of the “random” point you used to select either P or Q so as the attacker you only have a very limited search space to find the P or Q. And importantly there is no way to examine a public key and reveal the presence of this type of backdoor…

And people wonder why I don’t like PKI where the software to make your public key is supplied by the people running the CA…

Clive Robinson • June 7, 2010 11:49 AM

@ Robert,

As I said “and them some” 😉

Yes EmSec / TEMPEST is the best attack vector in many cases.

However it depends on if you want to do pasive or active EmSec.

Pasive is limited by thermal noise limitations to -174dBm for a 1Hz bandwidth which goes to around 15dB worse for standard POTS bandwidth to 20dB worse for cell phone audio bandwidth.

And when you look at radiation efficiency lossess for a surface mount inductor at 2MHz I would be thinking of going further up to it’s higher harmonics.

Oh and not all are buck converters some are series resonant so you might need to us PM/FM demodulation for better effects.

My favoured aproach would be active with a UHF beam to see if I could get cross modulation onto it. High gain compact antennas make for just one heck of an advantage.

However my reply was just about the digital side (Nick P tells me off if I wonder to far of topic 8)

The simple fact is I don’t think it’s possible to have a normal size mobile smart phone that can be considered secure in all respects just some.

Which brings us around to POTUS’s “crackberry” that some call the “Obamaberry” I would not have liked to be on the team that supposadly secured that…

I’ll have a small side bet (a bottle of good ale) that it is only secure in some respects and good old distance is what is used for passive EmSec pluss some “active EmSec attack” detection.

However I guess we won’t know for another 20years or so and I might not be arround long enough to collect 8)