Schneier on Security

Clive Robinson • January 4, 2014 5:02 PM

@ Bryan,

On a diversity of processor instruction sets in a system: I’m not sure it is needed or is even wise. It makes it much harder for one person or a small group to review the overall system, and it doesn’t impact a well funded group’s ability to attack it. At best it only provides a small hurdle to cross while providing impediments to assurance, especially by an underfunded volunteer group

Whilst I can see and understand how you arive at this it is an over generalisation which hides some distinct advantages.

For instance if I have three entirely seperate CPUs say MIPS ARM and another equivalent core, then it is extreamly unlikely that even a state level attacker has subverted them all. And even if they have then it is even less likely that they would be subverted in the same way for obvious reasons (one of which if it’s discovered on one it’s discovered on all).

Now if you put these three CPU’s in a “voting circuit” where they receive the same data and perform the same overall function any subvertion reveals it’s self by differing behaviour at the outputs which the voting circuit will detect. Thus you know that either a CPU has developed a fault or it’s been subverted.

Thus you can detect subversion at layers below (ie on chip) which you can see in any other way.

Now if you implement a P / H / F code “byte code” interpreter on each CPU you get your common language environment you identify from that point up the computing stack.

Now the state level attacker could try to subvert at the byte code level or above, but because you have control at a level under them the tables are turned and you can protect yourself from them because you can detect their changes.

Thus as Sun Tzu advised several millenium ago you get to “Know your enemy”, and with this you are both “In a battle ground of your chosing” and “Fight from a defendable position of strength”. Effectivly you are in a high position with the sun behind you looking down unseen on your enemy which from a security perspective is an advantage to valuable not to use.

Clive Robinson • January 4, 2014 6:51 PM

@ Sadclown666,

Back to the practical: What kind of computer setup is most likely to resist intrusion with these new facts in mind? A personal development/encryption machine, not a server. I am thinking Linux on an ARM, airgapped most of the time. I guess I should be compiling my own OS. Any practical suggestions on the best setup that doesn’t require me to build my own architecture or my own machine? Or perhaps does involve an easy machine build?

Hmm firstly you need a different view point to the industry norm.

Industry battle cry is “Integrate Integrate” mainly for perceived “efficiency” reasons. Security battle cry is “segregate segregate” mainly for behaviour “mandation”. Going back a long way on this and other blogs you will find me making the comment about “Efficiency-v-Security” in the same way people used to go on about “Usability-v-Security”. That is they tend to be regarded as mutualy exlusive in that you can have either “efficiency” or you can have “security” but not both. Whilst this is not true it is very very difficult to have both and it needs exacting reqirments beyond the abilities of most mortals.

The question is how to get the benifts of modern computing in terms of usability and efficiency whilst still maintaining security.

@ Wael has indicated one way which is to segregate out one critical security function into a seperate device, but whilst this is a good start it is not sufficient due to various problems. One of which is that if the attacker controls the keyboard and screen they can do a security end run around the critical security function in the seperate device.

The way to resolve this is to do a little more segregation, that is the screen and keyboard go through a mediation device which then goes through the security device through another mediation device and then to the computing device that only does one task at a time.

With further thought you end up with a fully segregated aproach which is basicaly each device communicates through a mediation interface that talks to a switching bus which links all the mediated devices together. The mediation interfaces and switch are controled by a security hypervisor that enforces policy.

In aproach it is like going back in time to the “big iron” systems aproach on which the likes of realy secure OS’s etc were developed back in the 1960’s & 70’s before all this “desktop nonsence” started 😉

However you take it a stage further in that you don’t have one CPU running many tasks, you have multiple segregated CPU’s running single tasks…

Now you don’t have to go as far as C-v-P to get quite a lot of security over and above that is possible with COTS systems and relativly cheaply.

Many years ago I had access to PC104 industrial control cards that had 386 or 486 processors on them running a striped down version of Linux that I was using to develop a “cluster solution” for a secure communications project I was involved in. These PC104 cards basicaly had the old 16bit ISA interface and you could get various commercial back planes for them with between two and twenty ISA conectors. To cut a long story short I ended up developing a mediated network card and used a 24 port managed ethernet switch. Managment of the ethernet switch and mediated network cards was done “out of band” from another PC104 card with multiple serial interfaces.

It did the job required for the project prototype very well however I started thinking on how it could be improved… Which started down the path which ended up with C-v-P.

Now what many on this site don’t realise is you can by embedded microcontroler chips for a couple of dollars these days that contain CPUs and memory that far exceeds high end mini-computers of the 1980’s and most have multiple peripheral devices on them including high speed serial interfaces that can talk to Digital Memory cards, USB ToGo and ethernet. Some manufactures provide nice easy to use “prototype” development cards fairly cheaply in one offs and will with a little arm twisting sell them at quite low prices in bulk.

However as noted above by others there is the Raspberry Pi, this has both USB and Ethernet devices and they are ridiculosly cheap for what they provide. So potentialy you have the ability to build a cluster in the same way I did with the PC104 cards.

But one thing I’ve done with some sub two dollar microcontrolers is make a PCB which provides a memory card slot, a USB interface and the other I/O Pins going out to an IDC connector (as seen on pre SATA HDs) that can be pluged into other hardware, hung of the end of a ribbon cable or pluged into a custom backplane bus. It’s these I’ve been using to prototype C-v-P (as well as many other projects).

In C-v-P I use them to run individual very small tasks kind of the equivalent of *nix command line utilities used for shell scripting. As in a *nix shell script I pipe the results from task to task, however unlike *nix where the pipes are IPC memory such as semiphors I pipe through the backplane switch. Rather than have seperate mediation devices I currently use the micro kernel on each CPU card for prototyping, however I have one or two prototypes of cards where the mediation devices are another micro controler that also acts as a MMU to access common memory securely and to do execution signiture checking. I’m also currently developing a very small device independent bytecode interpreter such that I can use any microcontroler that will run the interpreter, the kernel will be written in byte code as will the tasks such that I can implement a voting protocol extension.

Thus you can for a small capital out lay and a lot of hard software time build your own “malware and hardware subversion” secure computer system…

As for what passes as “usability” these days the best way to go would be a “thin client” display system with a “middle ware” system to turn command line processing into fancy graphics. It’s not an area that currently concerns me Google for all there other sins have produced via their various Chrome endevors have produced an effective graphical thin client likewise various small linux distributions. I don’t know if they are secure or not and don’t particularly care, as with a bit of thought any problems with them can be mittigated as has been discussed on this site quite a few times recently (see BadBIOS discussions). Likewise any middleware server.

I’m sure that @ Wael, Nick P and several others will want to pass comment, and I hope they do because free and open debate on these issues usually pushes things forwards faster than trying to think them out on your own (I know from past experiance I’m neither infalable or all seeing and likewise have limited resources such as time to do things).

Clive Robinson • January 4, 2014 7:53 PM

@ Compromises all the way down,

Couldn’t the attacker theoretically subvert every machine differently, but only cause different behavior (from the good state) in the interpreter ?

Depending on how you implement the voting it will pick up differences at any level.

Look at it from the data flow perspective, you provide the three CPUs with identical input data, you then compare the output data. If all three CPUs produce identical output data you are happy.

Now for an external attacker to change the interpreters they can only change one interpreter at a time, they cann’t change all three simultaniously. During this time the votes won’t agree thus it should (if you are doing things correctly) cause the attackers activities to be discovered.

It is possible for an insider with direct access to stop the system and change each interpreter prior to restarting the system, in which case there is no “disparity time window” for the voting circuit to detect. However there are other external to the system physical security measures that can be implemented to either prevent or catch such activity.

If however an attacker can get physical access to the system to make the changes then they can in all likely hood get access to other things much more easily and be able to “end run” around security, such as by puting in a method of reading key strokes (ie by vision and or audio bugging) in the area of the users keyboard (ie under table surface for audio or in ceiling tiles for video). Placing an audio bug under a table top can be done by slieght of hand in seconds whilst the user is there, so would realy be a lot lot less of an effort or risk for the attacker than trying to compramise the integrety of the system.

And “end run” attacks are realy the best way for insiders and most external attackers doing “black bag jobs”, they actualy carry minimum risk both of being “caught in the act” or the real attack target being identified subsiquently. Look at it this way if an audio bug is found the majority of people are going to assume it was for picking up conversations not keystrokes. But unlike conventional audio bugging it only needs to be deployed for a very short time thus with a little “human engineering” the audio bug could be retreived after just a few minutes or a day at the most.

It’s also easy for run of the mill IT Sec bods to not even think about end run attacks because they fall in that not often talked about “external covert channel” class which is generaly considered by most to fall into Physical Security –ie locks and bolts– not IT Sec. Likewise the majority of Physical Security bods would not see it as an IT Sec issue. Thus you have a massive crack in security that a savy attacker will play in very happily and profitably.

What is worse as a major software engineering department in a major company found, sometimes the Physical Security bods actually end run around the IT Sec. Basically to stop thefts of equipment a covert high definition remotely controlable IP CCTV device was fitted. This CCTV could clearly see keystrokes being entered, and the unencrypted IP video stream across the internal network was visable to who ever could be bothered to look at it… Ops.

Clive Robinson • January 5, 2014 7:49 AM

@ Ian Moffit,

Another source of inspiration for which much documentation survives is Seymour Cray’s…

His work –the last time I looked– still lives on in production machines (Sun Starfire systems).

Both Sun and IBM realised that the bottle neck in mainframe systems was not CPU speed but interconnection speed for communications with storage and other systems/users. Seymour Cray realised this as well (his background was the Intel community) and he designed an effective bus switching system which Sun purchased the rights to.

IBM likewise developed such switching that is seen in their Z range machines.

Multiple CPU systems with shared access to a switched back plane shared with memory and IO is the way to go. With the real limitation on what’s possible being the switch.

One method is to drop the old conventional “parellel bus” designs due to many issues and replace them with high speed serial buses, such buses can quite easily function at 6-20Gbit/sec these days so the bottle neck is the switch design.

I must admit for a high performance at low cost I’d seriously consider Gigabit ethernet managed switches with four or more connections from each computing block using iSCSI or simpler equivalent for all shared memory, storage and IO. Yes there are faster ways and yes there are cheaper ways but it kind of howers in a well supported sweet spot.

Clive Robinson • January 6, 2014 4:31 AM

@ Ian Moffit, Nick P,

You both/might find this site interesting,

http://www.cray-cyber.org/general/start.php

They have quite a bit of documentation up on line which is worth looking through but… that’s not why I found the site originaly,

If you look in their current hardware projects they are also building a Thermionic Valve computer from scratch and part of their reasoning for doing so boils down to “research” to find out why things were done a certain way,

http://static.cray-cyber.org/Hardware/PaperMUNIAC.pdf

@ Ian,

With regards the Raspberry Pi and your comment about foundations of sand, yes it’s a potential problem as is all modern hardware, and the lack of full chip documentation has been a reoccuring theam in that vein.

However as I’ve indicated a few times my belief is NO modern hardware can be regarded as trustworthy, thus you have to find ways to monitor or better mitigate in real time (it was one of the reasons I started down the C-v-P path).

If you think about “monitoring” even untrusted harware can be used as a “litimus test” to detect the unwanted attentions of attackers with zero day or worse attacks.

Put simply if you use untrusted hardware as your “garden gate” not your “front door” then you get an opportuity to see your attackers in your “front garden” not your “front room”. Whilst in the front garden they can do only annoying –not harmfull– damage, but importantly their intent is clearly identified as hostile, and this gives you time to respond before they can do harmfull damage.

Once upon a time we used to do this with “bastion hosts” and “De-Militerised Zones” watched over by guardian systems that could not be enumerated from the DMZ. It’s a stratagy that has much to offer that later “Firewall Apliances” just cann’t do.

So using one Raspberry Pi as a Bastion Host immediatly behind the already owned ISP router gives you your DMZ “front garden” in which you have another “instrument” host [1] that can see the DMZ but not be seen from the DMZ. The instrument host could be a second Raspberry Pi or other system running appropriate OpenSource software and controling a “hard gate” [2] behind which a non Raspberry Pi firewall sits that gives access to your “front room” internal network (or further DMZ / protected / sacrificial / honeypot zone).

[1] Instrument hosts have many names basicaly they are a striped down and hardend host running packet analysis software like any conventional IDS. However the difference is they only have one way cables connecting then to the DMZ network. Basically you cut the instrument hosts TX lines. My home brew way to do this is not to do it in a network cable –it always ends up causing problems– but to make an “Instrument head” which is basicaly a comercial off the shelf network surge suppression device and cut the TX tracks on the PCB.

[2] A Hard Gate is a device to “cut the connection” and effectivly air-gap the down stream network under the control of a simple signal. It’s quite simply made and basicaly consists of four reed relays in the TX and RX network paths. The reeds are “Normaly Open” and need to be energised to close which gives a “Fail Safe” element to the design. The energising signal comes from the Instrument Host, which at the first sign of problems drops the signal and the network is the equivalent of Air-Gapped from that point onwards untill the signal is re-asserted.

Clive Robinson • January 6, 2014 12:42 PM

@ Figureitout,

Simple answer is no.

Not for technical reasons, basicaly 09/10 was not a good time for me and I had more pressing things to attend to.

Also the calculator like a “faithfull dog” has now been “loaned and re-homed” by a family member supposadly to help with their education…

I guess your father would say you’ve been loaned things like tools / equipment that you’ve now re-homed. It happens in lot’s of familes and gives rise to the old joke,

“It’s had two new heads and four handles, but it’s still Grand Dad’s hammer”.