Schneier on Security

Clive Robinson • January 30, 2013 6:41 AM

@ examplesPlease,

Hence, I was surprised that your article… mentionned closed-source products

It’s a sad but true fact that you have no choice but to use closed source products when it comes to using computers.

If you look at the computing stack as starting at quantum physics and working up through transistor design through logic gates through gate cell macros that implement functions that make up memory through to CPU’s and very complex interfaces to the real world that make up Systems on a Chip products that then get a BIOS/OS put on them that then get applications put on those which in turn act like OS’s which then run code downloaded from web sites etc you quickly realise you only have a small bit in the middle (OS and Apps) that you have any real control over and can decide to make Open source if you wish.

That is from the CPU down is almost entirely closed source, and much web content uses closed source from the likes of Adobe.

Inherantly there is nothing wrong with closed source it’s quite agnostic in methodology and tools. It’s the humans that use them that have the intent, thus the problem is actually one of trust in that you can not verify what the maker “claims on the tin” unless they chose to let you.

And in turn those closed source products are based on other closed source products. Think for instance a System on a Chip for say a mobile phone. The chip designers use macros provided by other manufactures for the CPU memory voice and RF circuitry. in turn those macros are almost certainly based on other macros etc all the way down to and including the transistors. To get the chips manufactured they need to include other closed source proprietary parts so the basic chip functionality can be tested. These may be added by the chip manufacturer without the designer ever becoming aware of what is added.

So currently chips are closed source and potentialy full of bugs which might be backdoors either accidently or intentionaly.

But what about at the CPU level and up, well likewise it’s not any better. When you write your open source application in a high level language do you know what is in the library calls and wrappers to OS calls?

You might for a GNU tool chain but what if your app has to run on MS or other closed source platform?

How about on Android etc?

Although we chose not to think about it computing is currently based entirely on trust of closed source at some point in the computing stack, and this is finnaly starting to get people worried.

Think back to below the CPU layer, even if you could see the layout on the chip in as much detail as you wanted would you be able to work it out?

The simple answer is no, not even for the US Dept for Defence, which is why they are sponsoring research into how to knock some trust out of the chain and get some verification back in…

But even that won’t work… Because things are way beyond the point where a single human mind can sufficiently comprehend all the knowledge required to do a full secure audit of a system across the entire computing stack from quantum physics to level 8 and beyond. Thus you have to trust what is in other peoples heads, which is not tenable as a solution for various reasons.

So what to do…

Well actually you don’t have to trust or verify the components, just what they do in ways they cannot hide from you and remember it’s got to be a continuous process of testing because past behaviour is not a guarrenty of future behaviour, and in autonomous systems not even indicative (as things always fail).

If you want to know how you need to start with a riddle, about two guards on two doors where you know that one guard always lies and one always tells the truth. You then formulate a question that goes through both guards in a way that negates the effect of the lying guard. Such a riddle is thousands of years old and the question is still the same, “If I ask the other guard which is the wrong door which will he point to?”

It shows that you can negate a person who always gives a false answer, but what about when they sometimes will and sometimes won’t. Well this is when you get into the fun world of probability. It’s an important problem especialy with highly complex low reliability systems that might fail in a spectacular and extreamly news worthy way. It was a problem facing NASA during the 1960’s and the solution was “voting protocols”.

That is you produced a single specification that you gave to three entirely unrelated development teams who do not collude, they produced three entirely independant systems that meet the specification. You run these three systems in parallel where each receives an identical input. You then compare the three outputs and either go with the majority vote or halt the system if there is disagrement.

From these beginings you move forward in what I call “Probabilistic Security”.

You can test an individual part of a system by giving it a question to which you know the answer. If you ask this question of the system then if the answer is not correct then you know something is wrong with the system. If you intersperse this and other known answer test questions through the system when asking non test questions it gives you a degree of confidence that the system is functioning correctly. Obviously if you always ask test questions then you will know exactly when a system has gone wrong. If however you ask a test question every other question then you will know within two question periods. Obviously the ratio of test questions to other questions gives a window of uncertainty but it is better than having a very large number of parallel systems.

The problem is when a system goes intermitently wrong there is a probability that it will go wrong for a period shorter than the window of uncertainty. Thus the test questions produce a probabilistic detection of error.

There are a lot more things that you can do when you trade the impossible idea of absolute security with the idea of probabilistc security. One important realisation is that you don’t get the system to question it’s self you get a second system. That is you have say a two CPU system, one CPU is the work horse that does the actuall work, the second is the one scheduling in the test questions and examing the results. You quickly realise that this second CPU can actually be just a quite simple state machine that is not only fully determanistic but unlike a Turing engine every state it can be in is known and hard coded. If it detects an error it raises an exception and halts.

This can just as with the voting protocols be handeld in a number of ways. In one simple case it also raises an alarm to attract a human operator. In another the human can be replaced with another CPU that acts as a security hypervisor which deals with the issue in any number of pre-decided ways. Whilst the hypervisor is another seperate CPU, it can handle many pairs of workhorse and check CPUs thus making it’s cost shared across the system.

Once you accept the idea of multiple workhorse systems other possibilities arise. One such is if there is redundancy in the system you can actually halt a workhorse CPU without it’s knowledge and the check CPU can scan it’s memory and registers looking for signs that the memory has been tampered with by say the likes of malware being added.

If you want you can build such a system today with multiple motherboards that have a fast DMA access port on them such as Firewire etc. If built into a cluster the hypervisor occasionaly halts a motherboard, scans the memory looking for rougue code etc and then if OK lets it run again.

I built an experimental system that did this as a prototype a little while ago using a modified Linux cluster and the idea works. At some point I intend to develop it to take advantage of other ideas I’ve had. However the motherboard level is insufficiently granular to get the best out of the ideas but resources dictate what you can do in your own “lab” where getting custom chips is a fairly expensive business. I have however also built a system using PIC24 chips as the work horse CPU and PIC18 chips as the checkers and another to make an MMU under the control of the main hypervisor to test other ideas.

I’ve discussed some of these ideas with Nick P in the past on this blog across many threds (and I guess this is another thred to add to the list).