Schneier on Security

1&1~=Umm • March 27, 2019 10:51 AM

@ALL:

There are a number of sides to this argument that are often not mentioned but are realy the root of the problem.

The first thing people want is not to loose the use of things and the easy way to do that as in life is ‘keep copies of everything’.

The second is people want fast response out of their computers, the easy way to do that as in life is not wasting time ‘throwing out the garbage’.

The third is as in life it takes way longer to put things away in an organised way than it does to ‘just put things anywhere’

Importantly though it takes much more time to put things away when as in life you start to ‘run out of unused space’.

With the cost of storage droping to the point it only makes sense to price it in Giga (thousands of millions) or Tera (millions of millions) bytes. Thus you can see why, from a user perspective,

1, Data duplication is good.
2, Not house keeping is good.
3, Unorganised storage is good.
4, More storage is good.

Now lets look from the data confidentiality perspective,

1, Data duplication is bad.
2, Not house keeping is bad.
3, Unorganised storage is bad.
4, More storage is bad.

Thus in theory ‘What the market wants the market gets’. The reality is though ‘What producers marketing people think is good is what gets made’. As the marketers look for ‘mass market’ as they are easier to sell into niche / specialized / minority markets either don’t get produced for or if they do at a disproportianatly high premium.

So if you want reasonable levels of confidentiality / privacy / security / secrecy or what supports it, you have to in effect pay a lot more if there is a product, or go without and thus have to make your own mitigations if there is not.

Which brings about the question of knowledge… Put your hand up if you think you can cover all the bases in the ‘required mitigations’ for the entire life cycle…

You might have noticed I’m very firmly sitting on my hands… That’s because I don’t believe anybody can ‘cover all the bases’ not even a large team of experts. In fact every one should think likewise, because of times arrow.

Lets just assume that you know –which you actually can not– all the classes of vulnerability there are out there. Lets also assume that by some magical process you could cover them all today, what about tomorow or the day after?

The point is the defenders are allways working in the past and the attackers in the future, which leaves a gap you just can not cover.

The only thing you can do is mitigate as broadly as you can the known classes of attack and keep your fingers crossed.

The broadest form of mitigation is segregation, not just seperation or authenticated access control.

History shows that segregation of any form is hard and the greater the complexity of any system the harder it is.

Thus you have to look at the very fundementals of the system break it into parts minimize not just the complexity within those parts but flows of information into and out of them.

So saying things like ‘Full Disk Encryption at the disk’ is insufficient because the implication is ‘one key’ which ‘all users need access too to use the system’. Further the key is in use as long as any of the data is in use. Which is why FDE or other Disk Level Encryption only protects when the drive is not in use and the keys have been securely deleted.

The problem is for most systems you can buy the keys are not securely deleted or worse they are not securely generated. Humans are realy bad at remembering things accurately even four digit PINs defete many people every day. Thus the chance of remembering 256bits of truley random data is in reality a compleate non starter. So FDE like most encryption just moves the problem somewhere else, it does not actually mitigate it let alone solve it.

Just about every mitigation you try to come up with either is totaly ineffective such as ‘security by obscurity’ or it pushes the problem else where.

The problem with pushing the problem elsewhere is it creates new communications channels be they informational or physical. In either case they need to be made secure which just increases the complexity, thus likelihood of introducing a vulnerability.

Many years ago now our host @Bruce Schneier mad the observation that as far as encryption was concerned we had sufficiently secure algorithms, what we needed to do was go on and work on sorting out the key managment issues.

To be honest since then I don’t realy think there has been much effort let alown significant solutions found. We’ve primarily ended up with some lowest common denominator solution of CAs. Using asymetric encryption in vulnerable hierarchical human systems, which have compleatly unsuprisingly, have failed repeatably as history had shown they probably would. But to make it worse the ideas of David Deutsch appear to being getting ever closer to fruition. If they do then our current asymetric public key algorithms become very vulnerable…

Thus even though we can see an entirely new class of vulnerability approaching us, we have no choice yet, but to build systems around what we have even though the predictions are it will be vulnerable long before it’s expected service life is over.

Thus we actually know we can not realistically have confidentiality now or in the future without some other way more physical mitigations.

Thus information storage needs to be in a vault, and storage that is broken or at it’s end of life needs some realy serious ‘ashes to ashes, dust to dust’ treatment.

Boy scouts used to get told that before leaving their campsite to ‘Burn, Bash and Bury’ their garbage, which in many ways was sound advice. These days they are told to push the problem somewhere else, much as we do these days in the ICT industry thus our information ‘gets recycled’…

Time to start the forge and get the hammer out, carbon footprint be damed, go have some excercise if not fun 😉

1&1~=Umm • March 28, 2019 11:06 PM

@Coyne Tibbets:

“Let’s say I have a dark view of security these days…”

But is it dark enough?

I think it was @Nick P who said don’t use Intel hardware made after 2005. And others said use only hardware from ‘before the turn of the century’ but did not say which 😉

I guess the real question is not what hardware ‘they’ might have targeted / got into, but which hardware ‘they’ have not got around to yet.

It’s a fair bet that both Intel and AMD have been ‘got at’ and with ARM having Chinese Interests hanging around it via a Japanese company these days, there is the other ‘theys’ to consider.

Also with the runaway success of the Raspberry Pi foundation what have the secretive Broadcom been upto…

So how about MIPS 32 or 64?

This is a little over three years old,

https://www.mips.com/blog/can-it-run-bsd-the-story-of-a-mips-based-pic32-microcontroller/

There is a list of supported hardware for BSD 4.4 at,

https://github.com/sergev/LiteBSD/wiki

With this board,

https://www.olimex.com/Products/PIC/Development/PIC32-HMZ144/open-source-hardware

Being only 22Euros and easily made ready for a prototype board to add extra goodies on. From the blurb it should be able to support five other serial interfaces so serial terminals or SPI memory cards. Also 100Mhz ethernet, so connectivity should not be much of an issue.

Oh and there are other suitable PIC MIPS boards designed for Adruno shields to be added.