Schneier on Security

Clive Robinson • December 7, 2011 1:17 PM

@ Coyne Tibbets,

“Which is better? Obviously the former, but i seems that people prefer to hide their head in the sand, hoping that the latter never happens; even though it probably will.”

Actually from the point of “shareholder” value it’s the amount of percieved profit and thus increasing share value, with a secondary helping of dividend.

The Exec knows their bonus and importantly their next job in about a year is based on maximising return. So from their viewpoint anything that negitivly effects the next quaters figures is of the utmost importance which essentialy means “don’t spend money on bug fixes” “spend on legal representation on credit” is better value…

Clive Robinson • December 9, 2011 7:05 AM

@ Nick P,

“Yet, we’ve both come to the same conclusion: the hardware & firmware must be secure if the layers on top are to be called secure.”

But do they ?

Sorry I don’t agree with it as an over generalised statment it fails, and even in a more restricted scope it can be dealt with logicaly and if not practicaly as well.

To start of we need to examin the roots of the word Atomic and what it actually means in real terms at all levels.

Put over simply it means “indivisably, the smalest part possible”. Now if something can not be broken down further, what effect does this have on it’s security?

Security is a way of thinking rather than an actuality, that is nothing is inherently secure it’s how we design it to behave with other pars that puts it in the “secure” as oppose to the “insecure” method of behaving. And, as it’s also a mind set not an actuality it can change with time, thus our notion of what was “secure” say ten years ago may now be regarded as “insecure” without the system or it’s mode of operation having changed in any way.

The point is we start building our systems with atomic parts that are not secure and by imposing some kind of order we can make them comply to our current notion of what is “secure”. Thus at each and every level of the design and usage of a system it starts with underlying “effectivly atomic parts” that can built into a system that is either secure or insecure regardles of if those atomic parts are secure or insecure.

We’ve actually known this for several thousand years, there is the old story of the two automatons gurding a gateway with two buttons or leavers etc which if you use the right one you pass safely, the wrong one you die. You are alowed but one question, of either automaton, but all you know of them is that one always tells the truth the other always a falsehood…

The solution as we’ve know since ancient times is to ask one automaton which button the other automaton would say is the wrong button. The result is you get told the same answer irespective of which automaton you ask the question, because effectivly your single question is asked of both automatons and the falshood of one automaton is negated by the form of the question.

So a couple of important points to take away,

1, Use logicaly different automatons.
2, Use all automatons to derive the answer.

The only overrider in this particular case is that the automatons behave consistantly all the time but as I will describe later that is not actually a constraint that cannot be mitigated.

Now by far the majority of our systems use a single CPU or two or more identical CPU’s this is obviously a violation of point 1 above.

Also we tend to design our systems to be “efficient” which usually means that if there are two or more CPU’s they are usually used to do different jobs thus obviously violating point 2 above.

Although high asurance systems usually use several CPU’s in parallel and in some cases performing the same task. Few if any use different CPU’s. However the likes of NASA have in the past used different isolated teams to write software against the same specification and run this with a voting protocol to detect an unsafe condition in a three or more CPU system.

Needless to say the difference between “safety” and “security” is largly a semantic one and in some languages the ideas are covered by a single word. So it can be seen that the voting idea will work to detect some if not most forms of “insecure” operation by a minority of the CPU’s with respect to the majority.

So we have a known starting point for our secure design from effectivly insecure but atomic parts. So yes we can use SoC parts provided we know that they are genuinely different internaly at the higher levels.

Now the main objection is “cost of duplication” that is we have a system that uses three or more parts to do the same job…

Does this actually matter in the long term?

In most cases no, and infact actually if you go about it correctly it gains you something at a more moderate cost than the current ways of doing things.

To see this, think about safety systems in cars. If you took a 1950’s car and added all the modern safety features we’ve come to expect then not only would cars be prohibitivly expensive to buy, but the running cost with all the extra weight would so badly effect both fuel consumption and handeling it would be doubtfull if their utility let alone their safety would be improved.

But we can clearly see this is not the case especially in Formula 1 racing cars, many of which still use engines designed and first put in racing cars in the 1950’s. What has happened is that the safety features have been “designed in” not “bolted on”. That is by sacrificing a little efficiency in one place we gain an increase in resiliance, by doing this in several places the combined results are considerably more than the sum of the parts. In everyday cars we can see this in the use of Side Impact Protection systems and crumple zones, because they get designed into the monocoque. The result is a lighter stronger and safer car that would be possible by the techniques of seperate chasis and bodywork of the 1950’s. However there is a downside of the monocoque is if you bend it you often have to replace it in it’s entirety to regain the strength and safety, not the old “cut-n-patch” and “cut-n-shut” repairs of dubious safety of 1950’s repairs.

Now a little earlier I mentioned that there appeared to be a constraint on the two points of “consistant” behaviour and indicated that it could be mitigated. That is it can be “designed out” to a certain degree. Think back to the voting system, if one system produces a result that is at variance with the other two it is effectivly “switched out” of the system by the majority vote.

But in NASA’s and other safety critical systems voting systems this is generally regarded as a hard fault and the unit is switched out permanently. But a little thought shows that this is far from necessary provided the overall system follows the majority vote and one system disagrees the result is not in question, its just that you go from a majority vote system to an agree or fail system.

But what if you let it run on and it starts agreeing with the other systems again?

This is what effectivly you do in testing a system you find a potential fault but cannot repeat it you then let it run to see if it re-occurs, if not then you call it one of several names such as “a transitory fault” or “a non reproducable fault”. In both cases the error might be due nott to an actual failure of the hardware but a transitory effect caused by say an ionised partical. In communications systems you accept that transitory effects occure and these are not faults of the system, and you build in either or both threshold or error detection and correction systems.

Adding a threshold system to a three or more participant voting system allows for transitory behaviour likewise error deection and correction add to the reliability of the overal system.

In many cases the cost of adding these systems is at worst marginal and at best can provide significant gain at a lower overal cost.

The simple fact is that although we know of these systems and their characteristics and have applied them very successfully to safety systems and quite a few physical security systems we appear not to have considered them for computer security systems in the accademic community.

It is one of the things I’ve considered in the “Prison-v-Castle” idea.