Schneier on Security

Nick P • April 30, 2010 11:40 AM

I don't think anyone could enter (or remember) the answer to this one. It's a quote that would leave even the best shouldersurfers in agony.

Question: "What are your extended, unsolicited views on this rather broad topic?"

Answer: "We have had part of this conversation before, But I'll go through your points.

"So you've doubled the components (complexity)"

Err probably not (certainly not in my hardware prototype any way). Have a look at the diference between CISC and RISC architectures.

CISC was based on an idea that by making instructions "do more" you'ld save memory which was very very expensive at the time (upwards of 1000USD/64K). This is nolonger true and the problems have moved to memory IO bottle necks.

Thus most code spends more time being shifted around in memory than it ever does being executed, and the CPU blocks on memory...

A consiquence of CISC is so many instructions that you have a great deal of redundancy in the instruction set and this makes Malware attacks significantly easier (Make your own shell script in ASCII if you want to see why).

I would argue that dropping CISC in favour of RISC would gain significant advantages in terms of silicon real estate.

Thus whilst I have conceptualy "doubled" in fact I've thrown out most of the usless and un-needed "complexity".

So much so that you could put many general purpose compute engines under one restricted function engine. Which is actually adventageous.

"and done away with all our present-day programming languages (barring maybe asm or BASIC)"

Compleat twaddle, and you should know that.

If you are actually arguing that the majority of higher level programing language compilers and language tools are written in C or use the C library interface fine. But there is no reason for them to be, and your argument boils down to "C is the translation code of choice", and unfortunatly as most code cutters don't know how to behave safely let alone securely C takes it's bagage with it where ever it goes. Look at it this way it's like alowing a bunch of 5 year olds unrestricted access to a "tool shop without safety guards", you know it's going to end in a world of hurt for everybody involved.

With regards,

"... Harvard architecture is only marginally more secure."

That depends on how you use it. Because of C most Harvard architectures have been weakened, and it is this weakening that has allowed the gadget attacks to be possible.

As I said earlier we have had this conversation before. When you say,

" Harvard architectures still can be attacked with return-oriented-programming... so smashing the stack would still be fun and profitable."

I pointed out it was due to the "extras" added to the Harvard architecture that made this possible. Thus I posted a link to a paper that makes the same claim as you but clearly shows that it's the "extras" that are responsable. Thus I used the term "Strict Harvard architecture" to differentiate.

" - High-level flaws in software *cannot* be defeated by low-level design."

This is what many in the US call a "strawman argument". I can make the safest car engine in the world but it won't stop you putting it in a dangerous car, and it won't stop a drunk driver using it to smash their way home leaving piles of mechanical and human wreckage in their wake.

A simple way to make most code more secure would be to properly deal with "exceptions" in all their various forms. However this needs a fundemental change in mindset of a programer from "Gung Ho charge the cannon's down" to a more statefull way of thinking.

"Financial data transmitted in plain text would still be transmitted in plain text."

That is a fault not of the system or the programers but those at the top. And incidently in of it's self is not actually bad. You have to have it in "plain text" at some point to allow it to be processed. It is a question of where you set your boundries and how you implement them.

"Timing side-channels in encryption libraries wouldn't go away."

No but again this is not architecture related and it has some inherant problems that you appear unaware of (the problem came about due to trying to solve another problem, and in all likleyhood the solution will open up another attack for other reasons). The issue is doing crypto in software on an unknown platform.

"Bad RNGs (a la debian's openssl) would still expose your keys."

RNG's are (as you might know if you are a longterm Bruce's blog reader) a subject close to my heart. If you are refering to the problem I think you are it was actually a deliberate choice by a programer to make a change that made it insecure.... And yes the last time I looked there where still people out there using weak PK certs based on it...

"Heck, even path traversal would still be with us..."

Again an issue that is not realy anything to do with the CPU architecture.

And thus I can only conclude you don't actually understand the issue.

There are all sorts of "assurance" issues at every layer in the stack from the cluless/malicious (ab)user down to the wires and components that leak data via EM and audio radiation.

For a secure system you need to resolve all of the issues. This can be by fixing them or mittigating them it is a design choice at that level in the stack.

However fixing a problem at a lower level will not stop poor choices further up the stack leaking information at a high level.

Importantly fixing high level problems will not stop poor choices further down the stack leaking information at a low level.

Worse any fixes at a high level can always be side steped by "bubbling up" from a flaw at a lower level (when the flaw is to small to be visable this is also known as the "Champaign bubble effect" that is the effect of the flaw only becomes visable considerably higher up).

Most malware get's control by one of two routes, Through the user, or by "bubbling up" from a lower level.

No technical solution (other than maybe the bullet) can solve the user issue. But there are partial technical solutions to the "bubbling up" explotation of a fault or flaw.

The question is where and how do you expend resources to resolve the issues at lower levels.

One way is to get rid of a very badly flawed architecture that positivly encorages "bubbling up" by it's very inherant design.

The question then becomes will the market alow it.

Saddly at the moment we are stuck with the iA86 architecture even Intel admitted defeat and binned it's iA64 architecture in favour of the AMD64 solution. The question is will the "business environment" allow "natural selection" to rid us of this "Saber tooth tiger" evolutionary dead end?

Even it's designers Intel know it's doomed, but they appear locked in a "danse macabre" with amongst others AMD, driven on by the maddened cajoling of the carousing consumer market. Which leaves the question what happens when the music stops?"

*short answer:* I'm Clive Robinson, biatches!

Nick P • April 30, 2010 10:43 PM

@ peri

I was aiming for humor and relevance to the blog. Seems I hit the mark. ;) It took me all of 2 min to find a post long enough for the joke... without Google or bookmarks. Hehe.

@ Clive

Copyright violation! I thought all your posts came with an implied Creative Commons license permitting redistribution. I swore you gave me explicit permission one time... over an encrypted, onion-routed chat session whose keys are permanently lost. Yeah, seems pretty clear cut to me. ;)

Btw, that post was you arguing with some other guy about something. I left out his name as *that* wasn't funny. But, I'll forgive the mix up since we've had similar discussions and you were a good sport about it. ;)

Nick P • May 1, 2010 11:35 AM

@ Xentac

Just for kicks, I put that through a Latin translator. Of the 40% that got converted to English, I can't say I'm understanding it. The last line is the most sensible of them: "he is amet was vulputate spotless annoyance a quiver he is amet eget if not." If I am getting this, the security question asks if you are Amet, an annoying guy who darts like an arrow into places wearing clean clothes.

Nick P • May 5, 2010 1:25 AM

@ peri

Are you sure that is really secure? The people who often use password questions are those who don't manage their passwords well. Wouldn't some operators go for, "Damnit! I can't remember exactly which I used, but it's basically a long random-looking string of letters and numbers. I was too clever for my own good. You know it's me. How many people would guess that I used a random string?" I'm sure quite a few support reps would buy it.