Schneier on Security

Clive Robinson • October 9, 2010 7:18 AM

@ RobertT,

“The problem for me, is that I don’t believe that any human accessible system can possibly be secure”

Not quite true, “No system is” and by that I mean any and all non trivial systems irrespective of human access.

That is because it is not possible (even inside of a black hole) to have a system fully isolated from the environment it’s in. As the system has no control over the how where or what of the input theoreticaly and practicaly it’s internal state can be changed without the system being aware of it.

I’m fairly sure you are aware of the next bit but I’ll give it for the sake of younger readers 😉

For a real world practical example, once upon a time computers of all sizes used EPROMs to store code such as the “boot ROM” the assumption was that it was always “Read Only Memory” even though it was both Programable and Eraseable, and thus each time you read byte X you would always get value Z.

Well, the early EPROM’s had a very large transistor size etc, thus they had a high immunity to EM radiation except at very very high frequencies (Ultra Violet).

This ment that IR and visable light did not effect their operation so the little quartz window used to Erase the PROM did not need to be covered unless UV was around.

Well within a relativly short time the size of transistors etc shrunk many orders of magnitude as did the energy per device and all of a sudden the devices became susceptible to energy in EM radiation in the visable light and IR spectrum. Which ment if you did not cover up the little quartz window properly you would not always get a value of Y when reading byte X…

I’m old enough to have fallen foul of this and I wasted something like a week trying to track down random bugs in a safety critical system I was designing. The penny finaly dropped when I realised no bugs in early morning and late afternoon or when somebody blocked the sunlight falling on my work bench…

The problem today is not only have the transistors etc continued to shrink other factors are now involved. As any space engineer will tell you designing electronic systems for satellite systems is a real issue due to EM radiation up in the ionising spectrum causing “bit flips” and there is no way of detecting them all all the time.

Well some would say so what but some forms of radiation can pass right through the earth and at lower energy levels can certainly pass through the metal case of a computer through the chip packaging and into the chip where they might or might not flip a bit… don’t you just love probability 🙁

Well as NASA realised quite early on you just have to accept that there is no definate solution to the problem and use probablistic methods and “cross your fingers”. Which is why they have systems using not just parity checks and their better bretherin but also multiple different systems aranged in a “voting protocol”.

But even so any and all non trivial systems will remain susceptible and thus will in a probablistic time “take a walk in the park” and need a severe kick in the Non Maskable Interup known as a Hard Reset (Go straight to jail and do not pass go or collect your two hundred pounds ;).

Which brings us back to the question of “human intervention” can a human exploit this vulnerability, the simple answer is “if not today then in all probability tomorow” (hence my interest in EM Fault injection and side channels).

Which brings us back to your correct and more succinct observation,

“so it is only a question of how long it takes to hack the target system AND what costs are involved in the hack.”

But does not mention time / resource trade offs.
Which is in essence what your Open -v- Closed source argument is about. However for the downside in time to attack Open Source you generally have the “many eyes” (if open) and many hands to fix. You also have little or no “security by obscurity” mind set of closed source that gives rise to the “it ain’t broken unless you prove it and then we prosecute the heck out of you for having dared look” mentality that was endemic in “Closed Source” (and some would say still is).

However your observation of,

“Every barrier you can add adds security…”

Is problematical because,

‘Every thing you add increases the size of the system and thus complexity.’

The problem with complexity is that unless you are extreamly carefull how you deal with it you also increase the number of potential attack vectors.

That is you realy need to know what you are doing and there’s very very few engineers that actually do (even in the EmSec brigade). I think I’ve met maybe five or six in over thirty years as an engineer designing systems many of which have to be high assurance (and before you ask I’m still learning just as they where and I assume still are).

If you hunt back through the Bruce’s blog you will find I’ve made a few postings with relavence to this area when chatting to Nick P, some of which refer to what I call “Probablistic Security” or “Castles -v- Prison” architecture. Some of which are highly relevant to your question.

In essence what I’m looking into is how to get around the implications of the Church / Turing’s halting problem ( http://en.wikipedia.org/wiki/Halting_problem ) and the couple of not so minor spanners Kurt Godel came up with with regards undecidability via his incompleatness theorems ( http://en.wikipedia.org/wiki/Godel%27s_Undecidability_theorem ).

The aproach I’m taking is along the same lines as the physicists and mathematicians at Los Alamos during the development of the Nuclear Bomb (which Fermi had independently discoverd. several years prior to this). They realised that due to complexity there where some questions that could not be accuratly answered in a reasonable time or at all. So they looked at taking a “probablistic” aproach to finding answers and the Monte Carlo method was born ( http://library.lanl.gov/la-pubs/00326866.pdf )

The essential feature of Monte Carlo methods is based on statistical sampling methods where a random sampling is an efficient way to evaluate complicated and many dimensional nonlinear and complex problems ( http://en.wikipedia.org/wiki/Monte_Carlo_method ).

One of the issues with systems and security is Kurt Godel’s second incompleteness theorem shows that if a system (as described in the first incompleatnes problem) is capable of proving certain basic facts about the natural numbers, then one particular arithmetic truth the system cannot prove is the consistency of the system itself…

That is a General Purpose Computing (GPC) system as described by Church / Turing and. generaly called a Turing Engine / Machine (TM) is incabable of deciding if it is consistent to it’s rules of operation using it’s own rules. Or more appropriatly for this it cannot tell if it is secure or not… However within certain bounded limits a trivial state machine can check if certain aspects of a TM GPC are consistant, thus there is a rabbit hole in the usual arguments arising.

A simple example being the case of a State Machine Hypervizor (SMH) that stops the GPC and then goes through it’s instruction “code” memory and checks it is still unmodified and likewise with “data” memory which should be in a known state.

Obviously the SMH cannot stop the GPC and check to frequently otherwise the efficiency of the GPC would drop below acceptable limits. Thus it’s ability to check for memory coruption (malware or otherwise) becomes a factor of statistical sampling.

Once you have accepted the idea of a security hypervisor watching over your user work GPC system a number of other problems quickly drop out.

For instance the von Neumann arcitiectur ( http://en.wikipedia.org/wiki/Von_Neumann_architecture ) is considerably less secure, reliable and efficient than the Generalised Harvard architecture ( http://en.wikipedia.org/wiki/Harvard_architecture ). The pluss point for von Neumann is a general purpose computer with operating system is that in a single CPU system you can load in arbitary code as data and then execute it (which is a wonderfull proprty if you are malware 😉

However for most production applications code does not change and does not need to thus it is just the ability to load code that prevents the Strict / Pure Harvard Architecture being used hence the Modifed Harvard Architecture commonly in use ( http://en.wikipedia.org/wiki/Modified_Harvard_architecture ).

The solution in this case is to use the Hypervisor to load the code into “instruction space”, and one hugh sorce of malware attack vectors disapears. Oh and in reality most high end CPU’s these days are Modifed Harvard architecture internally the “von Neumann” bit is bolted on near the address and data bus outputs on the very edge of the CPU…

Then there is the issue of memory managment this is always an issue on single CPU systems as the CPU has to control it’s own memory which means smart malware gets to control the memory that can be executed from or not etc.

With a hypervisor system the actual control of memory can be done by the hypervisor and the GPC can just make a request for a change of memory size and usage etc which the hypervisor can either grant or deny. This means that the GPC under the influance of malware or corupted code memory cannot arbitarily change things and an attempt to execute data as code at the CPU instruction level will fail.

Obviously interpreters which base their execution in code space on values in data space will still be able to run which is another security issue, and also why even the Strict / Pure Harvard architecture is not defacto secure in use.

This can in most cases be solved by not having an interpreter or anything like it in production code, which unfortunatly can be a limitation on functionality. However the hypervisor can again probabilisticaly check the “interpreter instructions” in data space do not get changed.

I can go on and also talk about the various “execution signitures” etc the hypervisor can monitor whilst the GPC is executing but this is a long enough post as it is, likewise using the Unix shell script / command pipeline philosphy of pre-compiled little tools etc which takes the burden of secure programing off of code cutters.

The important point is to remember that the hypervisor is designed so that it can never execute code in the GPC memory spaces, thus stoping malware “bubbling up”. Likewise it monitors as many asspects of the GPC functionality as it can either indirectly by observing external GPC execution activity (signitures) or dirctly by stopping the GPC and checking the memory and other spaces for unknown or unexpected values.

The system is not perfectly secure (nothing ever is by definition) however it goes a long way to removing most ot the current used attack vectors, and others that are not currently used.