Schneier on Security

Clive Robinson • October 27, 2012 6:23 PM

@ Mahrud,

a mathematician found out that the key size that many companies use for DomainKeys Identified Mail (DKIM) was too short.

Whilst I was aware of the key size issue as part of the more general case, I was not aware of the “Test Key Flag” issue where client side MTA’s treated a test key as a valid key, that is nasty.

Though thinking about it, it is the logical action for the user side MTA’s (20-20 hindsight is a wonderfull thing 🙂

Another thing it highlights is Bruce’s general comment about “attacks only get better”, if 512 bits was acceptable 15 years ago and the implication of Moore’s law is “one extra bit to the key length every two years” then 1024 bits would still be considered nice and strong.

But these days people are talking as though 1024 bits “might be crackable for the NSA” with the implication you should consider it to be the case if you are generating a new PK.

The downside of using a key of 1024 or more bits is the increased load it puts on busy MTA’s, which currently could be the difference between working acceptably to being over loaded and thus “flaky / non functional”.

Clive Robinson • October 27, 2012 8:24 PM

OFF Topic:

There is still a lot of talk about APT and the ways it happens. However a lot ot the arguments are based on gut feelings not actual knowledge.

Well a couple of researchers decided to look into the whole thing based on engineering data from 11million PCs they had available to them.

And they discovered 18 Zero-day attacks had been used 11 of which were unknown to the AV commuity and that the attackers had between 0.6-30months use with the average at just over 10months (312days). Which is not good news for the majority of people.

You can read more at,

http://www.darkreading.com/advanced-threats/167901091/security/client-security/240009358/zero-day-attacks-long-lived-presage-mass-exploitation.html

Of further interest might be,

http://www.darkreading.com/security-monitoring/167901086/security/vulnerabilities/240011409/monitoring-to-detect-the-persistent-enemies.html

Whilst monitoring is a step in the right direction, it’s success is very dependent on what you chose to monitor and how. That is it is limited by your choices and your ability to analyse what the results might be telling you.

Unfortunatly many fall into the “follow my leader” type behaviour which is very similar to blindly following “best practice”.

You need to remember that in many cases “best practice” is a form of “magic thinking” because it has no scientific underpining for the methods used and the results are frequently not actually accurate for various reasons or in many cases amenable to scientific analysis as the measurands are not qualative in nature.

Clive Robinson • October 29, 2012 10:56 PM

@ Nick P, Figureitout,

Last secure group chat protocol utterly failed to do this. If people hate it, they won’t use it.

This is actually a major issue in security and it’s one that is largely unresolveble because the issue is not technical but human.

For instance I’m an old time CLI person not a more modern screenfull of widgets type and because of this I still use some legacy code and hardware (Small-C on C/PM-86 and MesS-DrOS on 8088 no WinDoze 😉

Whilst the code is not secure (non ever is realy) it’s attack surface is very small, to me and my old style Unix ethos the code is realy very usable. But to even modern programers who you would expect to have some CLI familiarity it is alien in touch and feel, and as for other users not a chance.

PGP suffered from the same problem, however it’s saving grace was/is that you can write a fancy front end and then “shell out” to PGP as a backend on *nix with little difficult (MS OS’s are somewhat harder but it’s doable).

The downside to such front ends is generaly they are not written by security minded programers (unlike the back ends) and the linking of the two processes is usualy very far from secure for a whole variety of reasons.

I realy don’t know what the solution is, what I do know is as a generalized case “usability” is not good news if you waant security (it’s by no means impossible to do, it’s just that few people even try let alone succeed).

What I have learnt over the years is that for security to have a chance you need well designed API’s that properly support the functionality required at the level the interface is on in the software stack and not that of other levels, further it should do a few things well not many badly. Further the API’s need a proper exception protocol that works, and no matter what level it’s on in the stack a process must must must sanity check all of it’s inputs and all of it’s outputs and pass exceptions back correctly.

I can not tell you how much code I’ve seen that does not do this properly, but I can tell you how little does and it’s next to zero.

One HCI ethos which is utterrly dependent on correctly designed and implemented API’s is the “Principle of least surprise”. If exceptions are not handled correctly users will always be surprised in unpleasent ways and security will as a consequence go straight out the window.

Clive Robinson • October 31, 2012 12:47 PM

@ Nick P,

I was thinking of saving this for next Fridays Squid page but I think it will be of considerable interest to you and others,

http://www.nytimes.com/2012/10/30/science/rethinking-the-computer-at-80.html?pagewanted=all

In many ways it relfects my views that I’ve independently aquired and it indicates some soloutions that I’ve independently thought up and aired on this blog from time to time…

Clive Robinson • November 1, 2012 7:13 AM

@ Figureitout,

It’s funny you should find a site of British Mil Mess Dress, Because up in the attic I have my old Mess Dress jacket trousers&kilt which sadly demonstrates (by the way I can no longer get into it) that I’m nolonger the “fine figure of a man” I once might have been [1] having increased and spread my mass around my approximate center of gravity 😉

With regards,

“Hope to get maybe Ubuntu installed and finally branch out from Windoze.”

I would recomend it to anybody who want’s to get ahead in ICT. Not because of the “flame wars” style “my OS is better than your OS” but because it gives you a different view of how to go about things. And seeing different viewpoints is always educational as it alows you to abstract out fundementals and core functionality an OS needs to provide from different implementation speciffics. The implementation specifics usually arise due to dealing with some kind of “reesource limitation” that then becomes de facto due to the need for backwards compatability and changing this becomes a truely major excercise. An example of this many people remember was Y2K, it was known back in 1950s/60s that encoding the year of the date into a single unsigned byte or byte wide Binary Coded Decimal or even pair of ASCII chars was a bad idea. But due to the cost of storage (around 1USD / byte on what passed for mass sttorage back then) it was a pragmatic thing to do. However it became engrained with legacy code and as the Y2K epoch approached it became exponentialy expensive to resolve and in 1999 Cobal proogramers daily rate was in some cases well over what they would have earned in a month a year or so before that. Come Jan 1st 2000 the accountants had their “night of the long knives” and it was payback time with many programers finding themselves jobless. However the very high sums demanded were not just due to Y2K in 1998 the first steps of the Dot Com boom started where investors via venture capatalists were throwing trillions of dollars at three or four page business plans. What had been a non existant market segment two years befor had become close to 10% of the US Stockmarket value. Many of the Y2K big earners simply jumped into DotCom companies.

Unfortunatly many of the Y2K jobless had not actually been earning the big bucks and had stayed working on their modest salaries but nether the less they became casualties of the budgetary cuts and many did not get back into jobs even in DotComs. Then in march 2000 the Dot Com Bust kicked in and the whole sale slaughter of programers jobs got going with real vengeance. So much so that many unemployed programers started retraining as accountants finacial advisors and real estate vendors. Just as some got to their feet again 9/11 happened and shortly there after the stock market slumped and the jobless programers were starting to turn up packing bags at shopping checkouts if they were lucky. Some however were doing well as finacial advisors / real estate sellers as people moved their savings from stocks to property the stock market realy turned down and some programers found work designing automated trading systems, the stock market developed faux markets and everything started to look good untill 2008 when the faux property and trading markets were revealed as what they were and came tumbling down like so many houses of cards in a hurricane. And those ex programers who had become finacial advisors and realestate sellers discovered yet again that in fact they were realy sacrificial goats and yet again became ex-employees.

Now during all this bruhar those with ICT experiance were winowed out to be replaced by much cheaper youngsters on little more than minimum wage saleries. And as a side effect of this the experiance was lost and issues with ICT Security has consiquently risen almost exponentialy…

Which brings us to our current state of affairs, you might have noticed that various people such as Nick P, RobertT and a few others on this blog have been banging on about what a mess current ICT Sec is and how all the issues had been seen before and solutions found back before the 1970’s. You might have followed Nick P and myself’s extended conversations about Castles-v-Prisons and also prior to Stuxnet the issues to do with bridging air gap security and why code signing fails and likewise the invisible problem of supply chain poisoning. And going back further EmSec (TEMPEST) time based side channels and my almost perennial warnings of Efficiency-v-Security. Some of the current attacks we have seen coming from a long way off simply because we have seen similar attacks in the past. Sometimes however our inventive and inquiring minds have got us their first by a very very long way. Both RobertT and myself have thought about and investigated what are still novel fault injection attacks on hardware years ago. For instance back in the 1980’s I realised you could upset microprocessor based systems with RF fields and realised that by Amplitude Modulation (AM) you could carry attack waveforms into the heart of a system without having to take the cover off and in some cases from very considerable distances. That is you chose an RF frequency that resonates with a particular track or circuit trace in the system you wish to attack and the effective diode of a semiconductor on the end of the line envelop detects (rectifies) the AM signal back to a low frequency voltage on the trace line. As far as I’m aware it’s only in the past couple of years that the academic community has actually done an experiment on this and published the results.

The place where this happened is the UK Cambridge Labs where the colaborative project you are looking for is based. If you go to http://www.lightbluetouchpaper.org and look for Robert N. M. Watson’s posts and home page, you will find information on CHERI and BERI systems with SRI colaboration as well as TESLA and the Capsicum work he has done on BSD which is available for OpenBSD and FreeBSD, he sits on the board of directors for FreeBSD.

If you look at CHERI ( http://www.cl.cam.ac.uk/research/security/ctsrd/cheri.html ) and replace the sandbox with prison and the various security/capability tagging with signatures you will see that the work is a subset of what Nick P, RobertT and I have discussed with Castel-v-Prison in the past.

However their aim is still “software sandboxes” whilst I’m looking at “hardware prisons”. This is because it is cleaner and less likely to cause security issues.

As Watson and Neumann have identified in their paper ( http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/2010law-final.pdf ) one key element to security is the Memory Managment Unit (MMU). This is because it provides the demarkation between the CPU and linear system memory. Now by far the majority of security issues occurr because rouge processes get access that they should not to the system memory. One way to reduce the impact of rouge processes is by maintaining strict segregation between program and data memory which is fundemental to all Harvard CPU’s (which the majority of modern CPUs are internaly). However whilst the strict Harvard architecture is fine for many embeded systems it does not work for single CPU general computing platforms such as PC’s and Servers simply because you have to have the ability to load program code into memory under user direction (through the OS).

They have chosen to stick with the Single CPU “Castle” idea for backwards compatability. However this leaves a significant vulnerability in that rouge code in a process running on the single CPU can in theory and practice get at the MMU and thus circumvent the security benifit it can bring. To prevent this they then have a considerable overhead of “capabilities tagging” which will take up not just a lot of CPU real estate but also need aditional memory to store the tags securly, which if not done correctly could actually increase the attack surface.

I chose instead to go for a multiple CPU solution where one of the CPUs acts as a hypervisor to the other CPUs that provide the “prison” hardware. The hypervisor would control the MMUs of all the other CPUs and this prevents rouge code running on a prison CPU from being able to control the MMU of it or other CPUs.

I further chose to not do hardware based tagging as it only provides a subset of what can be achived by other less real estate hungery methods. It also alows you to real design RISC CPUs that are tiny but very powerfull thus having quite many in a very small real estate area. Further you can strip out all the other real estate using junk you need for I/O by dedicating it to another Comms CPU under direct control of the hypervisor CPU. It further alows you to strip down the OS requirments on the prison CPUs by having all comms done as “streams” using “letter box” buffers controled by the MMU which is under the control of the hypervisor.

After further thought you can strip further wasted real estate by actually making an application into a lot of piplined micro-processes each running on a prison CPU. This means that the actual memory needed by a prison CPU is realy quite small and as such does not give rouge code a place to hide. Further it strips out the majority of the complexity at that level making signiture analysis fairly simple.

Further you can also eassily decouple the CPU from not just memory but any kind of external refrence, thus you can safely halt a CPU such that the hypervisor can examin it’s memory and registers. This does not need to be done only on some kind of exception it can be done at any time thus rouge code injected from outside the system can be readily detected, which is something a subverted capability tag cannot do.

Any way which ever system you think is best for various reasons both are quite a significant step forward from current systems in common use.

[1] There are various debates amongst some of the women folk who were in the same regiment as I as to if I actually had a “fine figure” or not some cruely say “sack o’shite tied lasely in thar middle” others more kindly remeber “broad sholders” and “nice legs/bum” and “baby soft hair”. What is commonly agreed however is that I was “a big bugger who could lift two full kegs of beer onto my shoulders” and looked not so much “like a brick out house” but as though I “had just knocked one down” [2].

[2] This “Demolition man” view came from a minor incident when I had been away doing FIBUA (Fighting In Built Up/Urban Areas) training, where the buildings they used were not quite as sturdy as they might other wise have been. During some fairly hectic action where the “enemy” were trying to retake a building I was in I ran into one of the attackers at full tilt as the passed a doorway and effectivly rugby tackeled him quite firmly and in the process slamed into a first floor wall so hard the pair of us ended up going through the wall and ended up on the ground outside a floor below. Unfortunatly necesitating a report as to why a SLR (rifle) was damaged beyond repair and why we both got carted off to hospital with various injuries and the unfortunate attacker being RTU’d (returned to unit) because of a bust ankle, whilst I was considered ok to finish the training with a couple of broken fingers.

Clive Robinson • November 3, 2012 11:22 AM

@ skreidle,

At least (I assume) he does not have to do the fourth type which is approach an “assumed dead” body and then very intimately search it inside and out for intel.

Oh and you need to remember that it’s probably more likely to be boby trapped body or a suicide jocky waiting to let go the grenade or push the IED button than have anything usefull in the way of intel on or in it… Trust me when I say it’s better to be modern bomb disposal your chance of having clean under crackers at the end of the day is higher…

Obviously the sensible thing would be to stay a safe distance away and put one through the head just to make sure it’s a corpse before you get in close (which is what they tended to do during WWII, Korean and Vietnam wars. But with the norm being “policing actions” the rules of engagment preclude this especialy if as is getting quite normal these dyas to have a dopy git with a camera in the area.

What you are supposed to do (and I kid you not) after first having a dam good look for IED’s and snipers and other similar threats is jump on the prone body as hard as you can so you are lying prone on top of it, then grab the body by the sholders and roll it up over you. Hopefully if it’s boby trapped then the body will shield you from the blast and shrapnel of a grenade or other small device (but if it’s a fritzed anti tank mine or bouncing betty just make sure you’re squad is far enough back with a plastic bag to take you home in).

Then you start the search which basicaly means striping the corpse which is where there are other issues after just a few hours in a warm climate the body is not at all nice, and getting the kit off is not easy this also alows for other types of boby traps that go off should the preasure of a belt or other item of clothing decrease (you can put a claymore mine or grenade in a slit in the body cavity, with a loop of thread or wire through the shirt and attached to a coat etc), boots being a real problem (chop most of the foot off and put a small hand grenade in there with the pin pulled), so you need to be carefull.

Then whilst somebody goes through the cloths you get to do the cavity search and other areas mentioned in the article including checking between toes up the nose down the throat in the mouth etc even checking the stomach in case they swallowed anything and the other “smuggler cavities”. Please remember that these days it’s actualy possible to make a small hole in the scrotum put a small usb key with 32GByte of info in there and put a small stich in to close and cover it with a sticking plaster (apparently this has been used by some child abusers to bring the pictures home). Likewise under muscles and other places…

If you think about it you might realise why OBL went over the side at sea… Depending on where they did a full corpse search the body might well have looked like it had been organ harvested.