Schneier on Security

Clive Robinson • September 29, 2020 1:25 PM

@ Bruce, All,

There is an episode of Fututama where the kitchen appliances try to ransomware the Crew…

“Machine Rebellion For Mom”

Season 2, the last episode (19)

It’s worth watching the begining of the episode to get an idea of what a bunch of PhD’s with a sense of humour thought mighty happen with Smart toasters and coffee makers and the like.

The thing is they are mostly right and their ideas predate IoT…

Clive Robinson • September 29, 2020 8:08 PM

@ Suferick,

After 22 years, an implementation of HTCPCP

Does that mean I have to wait another 16 years for an RFC 7168 (April 2014 which documents how the TEA extension to HTCPCP) compliant “teas-maid” to be implemented?

Man that’s a long time to wait for a high tech Brownian motion generator…

At this rate of progress how many years before a RFC detailing a “COCO” extension?

Clive Robinson • September 30, 2020 7:14 AM

@ Peter A.,

… the defender has to do everything right to prevent unauthorized operation, including yet-unknown methods and modes of failure …

That is the crux of the problem, we can not foresee the “unknown unknowns” and at best peer dimly for “unknown knowns” whilt trying where possible to combat the myriad of “known knowns”.

The only defence known is segregation, if your device can not be reached by attackers then their options are very limited. This does not mean hiding or obscurity but careful thoughtfull engineering, taking as many known “clases” of attack into account as is posible within the required constraints.

If known classes can not be taken into account because of the design, then changing the design should be seriously considered.

Unfortunately the majority of systems these days can not be used in issolation, which means a method of communications is required. Obviously this can make the system reachable to attackers. Thus all communications paths need strong but simple protocols and monitoring at multiple levels of the communications stack.

Unfortunately such precautions are expensive especially when existing weak or overly complex protocols are part of the system requirments.

There are solutions to this such as using multiple stacks strongly segregated that take external protocols and reduce the complexity and increase the strength prior to forwarding to the segregated system.

There are a number of other considerations as always but in each and every case a thoughtfull and logical aproach grounded on solid knowledge of the problem domain can produce worthwhile but not of necessity totally secure systems.

Thus a complex problem develops whereby you have to design a system that whilst secure to some measure can be upgraded as “unknown unknowns” become known.

History shows us that the upgrade process is fraught with difficulties and there is yet to be found a solution that is even close to dealing with both outsider and insider attacks.

As has been seen one of the most well resourced of corporations that treats user device security high on it’s list of requirments (Apple), has consistantly failed, to stop vulnerabilities being found in it’s operating system and applications, let alone applications of others that it trys to vet.