Schneier on Security

Clive Robinson • November 3, 2011 5:50 AM

@ grymoire,

“First you needed to submit a 3-page “white paper” that answered 3 questions”

The answers to the questions are actually increadably brief and are as Nick P noted reliant on taking the correct outlook.

For the first question the answer should be “Do not develop any technologies”. We already have more technology than we know how to use properly.

For the third question the answer should be “Do what is required to answer question 2”. This is because the two greatest threats we actualy face are “fallback” and overly specific “standards” not what we should have is “standards of methodologies forming frameworks”.

For the second question the big problem is “percistance of implementation errors”. If you look at something like an electrcity meter it’s expected life time is 25-50years currently, we don’t have security standards that old, worse most of the standards have side effects that render the practical implementations all but insecure compared to the theoretical security (think AES and loop unrolling / cache attacks / timing side channels).

Now currently most embeded solutions either cannot be upgraded or cannot be upgraded securely. This has a knock on effect in that other systems still have to work with theses set in stone systems.

Thus when an implementation, protocol or specification error that can be exploitedd is discovered the only options are to “live with it” or “rip them all out”. Neither is a secure solution in either the short term or the long term.

As we know the “industry” concerned will first go into denial, take legal action against anybody who raises security issues against their products, pretend they have the solution in hand whilst hoping it will all go away, as they cannot afford to address the issue.

This lack of “upgradability” is due to device purchase price, essentialy embedded systems are extremely price sensitive and have small profit margins. However the most expensive part of embeded systems is usually the “instalation costs” and this can easily be twenty or thirty times the price on any given unit.

So a mass replacment of embeded systems such as electricity meters is not going to happen…

Thus the solution to the issues is “mandatory standards compliance” which you can see working with the European Union compliance “CE” and exception “(!)” marks, and in a more limited form the standards required for automobiles that in the US derived from the “Lemon Laws”. This means that all electricity meters would have to meet as a minimum the mandated standards, which would stop “the race to the bottom” in the quest to produce something at ever decreasing cost.

However the issue then moves to the “standard”, one of the problems NIST and others have in the ICT Security area is producing very specific standards not frameworks. If you look at the EU CE standards they are hierarchical with a broad framework at the top less broad framework at the next level moving down through various “replacable” specifications that become more specific as you go down the stack.

Thus a standard for the security of an electricity meter (and many other devices such as insulin pumps etc etc) would have as a requirment the ability to in place upgrade modules containing the base standards in a recognised way.

Importantly the standard must include a method by which insecure moduals must be removed permanently to prevent “fallback attacks”.

The standards should also contain a provision that the systems that connect to the embeded systems should likewise remove any modual that is connected with protocols etc that have been mandated as insecure or out of date.

So to answer the second question DARPA should actualy get their heads and efforts around developing frameworks of standards that effectivly remove the broad categories or classes of attack that are known to afflict low cost embeded systems.

However I suspect that my take on the three questions would not be popular with the powers that be within DARPA so I doubt I’d get an invitation 😉