Me at the RSA Conference

This is my talk at the RSA Conference last month. It's on regulation and the Internet of Things, along the lines of this essay.

I am slowly meandering around this as a book topic. It hasn't quite solidified yet.

Posted on March 3, 2017 at 2:06 PM • 13 Comments


Ross SniderMarch 3, 2017 2:19 PM

Please make recommendations that empower consumers and curtail mass surveillance. You have a lot of reach. Regulation of IoT could easily become a surveillance issue and this is far, far more important than the DDoS issue.

K.S.March 3, 2017 2:45 PM

I encourage you to publish this book before we get Internet weather due to IoT DDoS storms.

K.S.March 3, 2017 2:50 PM

We don't accept power supplies that electrocute people. At the back of each laptop power supply we have dozens of certification labels, including UL and CE. This didn't make power supplies unfordable, but it did largely stop electrocutions and fires. It is time we do the same with IoT.

90March 3, 2017 5:42 PM

It's strange how you use the term "real world". For me the world of computers is real.

Maybe you could say "the old world" or "the analog world".

Bruce SchneierMarch 3, 2017 8:08 PM

"It's strange how you use the term 'real world'. For me the world of computers is real. Maybe you could say 'the old world' or 'the analog world.'"

Good suggestion.

I know my terminology isn't great.

Clive RobinsonMarch 4, 2017 5:27 AM

@ Bruce,

If you are going to write a book on IoT, it would be wise to have atleast one chapter on the economic incentives that put multi billion dollar plant such as oil rigs/platforms amd Nuclear and other power stations "On Line".

It should identify the problem of "cutting cost by any means" as a mantra practiced by accountants and managment, often with perverse short term thinking without regard to envisioned or even clearly known risk.

The fact that another mantra of the "Free Market" has very predictably produced a downward spiral that has become a race for the bottom. Which has made such billion dollar critical infrastructure not just fragile but brittle beyond belief and hostage to the whims of teen and preteen social outsiders. Supposadly sitting in their bedrooms exploring this fragile intangible faux representation of a physical reality with blunt instruments swung with an ineptitude of the unskilled using massively powerfull force multipliers. The real question being why the inevitable has not happened.

Further another chapter as to why even simple low complexity example software is not nor can not be secure. Further how certain types of software (Rowhammer etc) can via side effects reach down the computing stack to the lower levels of hardware and by "active fault injection" strip away any security implemented at higher levels. Then discuss the implicit faults not just in software implementations but of the protocols and standards they implement and how they can be exploited.

Further the usually brain dead way that Errors and Exceptions from flags and signals are usually handled even when "try / catch" is implemented.

Also why this means that "formal methods" have limited applicability and work at way to high a level in the computing stack, thus can be easily subverted at lower layers.

And it would not hurt to mention that like "usability-v-security" "efficiency-v-security" can open up a whole barrel of worms with regards side channels, that can.and do make systems transparent in both directions. Such that faults induced on the outputs of some systems can reach back through many security layers to effect the components at the heart of the system and thus break security. One such example is the care needed with "random sequence generation" and how the contents of entropy arrays/pools can be negatively effected to an attackers advantage (also Rowhammer).

In short show why software as currently designed can not be made secure from malicious intent, thus why even minorly critical systems need to be segregated from the world that socialy inept teenagers and worse inhabit. Which means certain software designers also have to be well practiced in various EmSec domains.

supersaurusMarch 4, 2017 5:55 AM

@Clive Robinson

your comment has enough ideas for more than one book. I found it depressing, not because I disagree but because occasionally having a bag over one's head improves the view.

one nit: "...a mantra practiced by accountants and managment...". I disagree with you there, an accountant is like a thermometer or a hand grenade; they are just tools to measure things or find tactics hidden in the law. unfortunately managers, who are the accountants' masters, especially high level managers (e.g. the ceo), seldom pay any price for the bad things they do. if profits are up, they get a bonus. if they are down, they get a bonus. if they get fired they get a nice severance pay as written into their contract by their buddies on the board of directors and go on to their next ceo job. (no, I'm not an accountant). when actions have no consequences there is no deterrence. look at ceo bonuses in non-US countries, or look at them over time, say from 1950 to now, vs profits.

Clive RobinsonMarch 4, 2017 11:03 AM

@ Bruce,

Minor niggle,

We're building a world-size robot, and we don't even realize it.

It's a globe straddling communications network and by no means the first. The first would be the telephone network, which with it's leased lines formed the original foundation for the internet. Further we were also connecting sensors etc to those leased lines atleast as far back as the 1950's.

The real difference if you will is the incredibly cheap SoC devices with one or more 32bit MCU's more powerfull than micro vaxs and the like with ten to a hundred times the RAM with clock speeds fifty to two hundred and fifty times as fast augmented by DSP cores that have a performance few could dream of even in the early 1980s. As for communications speed that is tens of thousands of times as fast.

And it is the last point that we need to realy think about it's not uncommon to find homes in western cities with 100Mbit/sec connectivity. Back in the late 1970's to early 80's even major trunk networks backboning countries did not have that bandwidth and the majority of modems that were starting to appear in western middle class homes were often 1200b/s down from the telco and 75b/s up or less, and the ARPA Net was starting to escape the bounds of the US Military and academic communities.

The original DoD network protocols were designed to be as efficient as reasonably possible using 8/16 bit computers with 10MHz or less clock speeds, and due to instruction set issues certain choices were made. Thus the protocols had various assumptions "baked in" along with little or no error detection or correction outside of "data on the wire" thus the ill defined network stacks were prone to problems due to timing issues not originally catered for in the standards or protocols. This has due to compatability issues stayed with us to a certain extent. Other issues (ARP, BGB etc) have likewise stayed with us, thus security issues are in effect "built in".

Kurt SeifriedMarch 4, 2017 2:47 PM

One thing I keep wondering about: we can have awesome tules today that protect consumers from surveillance, and that's good. But if the laws ever change (e.g. Patriot Act) AND the new laws use the software update functionality of IoT devices, e.g. many IoT receives over the air mandatory updates unless you firewall it, but doing so will break functionality in most cases, to say nothing of mesh networking/etc in the future what do we do? We can't protect against the law in a technical manner unless we somehow give consumers more control over their devices and updates, which on the flip side means a huge pile of out of date IoT and the problems that brings us.

I don't see any easy answers.

Charlie Todd March 4, 2017 6:43 PM

I've been digesting the regulatory angle ever since you brought it up. I'm starting to think that populist governments in the US and abroad are increasingly against any regulations. Perhaps liability law or a similar type of legal risk is more likely.
It could look like a security "researcher" (defn ??) who reports a flaw would be required to wait 60 days before public disclosure, but the company or group behind the free software would have 10 days to publicly assign a CVE-like identifier. After 60 days, if a fix is not available, the company/group is liable. Punishment is limited to either loss of the right to distribute (multi-country issues though) or a fine if the company or group has financial assets. Important point is to give ISPs someone to sue since they are party to active exploits.
This doesn't do anything for zero day exploits and accountants are well known for not owning assets, but rather licensing everything to avoid making a profit. Important to address that.

Clive RobinsonMarch 5, 2017 6:57 AM

@ Kurt Seifried,

We can't protect against the law in a technical manner unless we somehow give consumers more control over their devices and updates, which on the flip side means a huge pile of out of date IoT and the problems that brings us.

Actually you are wrong because you are "thinking inside the box" or more correectly the communications channel. And you are not alone in this false assumption as I've pointed out over the years here.

If you think back to what was done in the Victorian era and back to almost the time man first started to write you will see they had solved this problem.

To describe what a diplomat would have done to send a message back to his government keeping the contents private.

He would write his dispatch in plaintext, give it to his private secretary who would use a code book to turn the message into "codetext" this would then have been given to a cipher clerk to be "super encrypted" to produce the final "cryptotext" which would then be sent by some untrusted communications system such as the postal service or telex system.

What is clear from this is the divison of process and how the untrusted is kept issolated from the trusted. There are two basic ways the security can be breached. Firstly by obtaining the ciphertext in the communications channel and crypto-analyze it --or decipher it if key is known-- back to codetext then in a similar way back to plaintext. Secondly the attacker can try to get access to the codetext or plaintext at either the diplomat's office or at their home governments foreign office department where the messages are filed.

Most modern cipher systems at the algorithm level are thought to require too many resources for cryptanalysis on individual message or link level usage (though Diffy-Helman weakness for mass usage was just possible). Which means that cryptanalysis attacks on encrypted communications should not be possible in the communications channel. But for many this does not appear to be the case with modern systems, which is where your "Technology -v- legislation" foreboding comes from.

Which means that either there is a weakness in the system implementation --which there is-- and/or the attacker has the ability to get at the plaintext --which they do-- by "end-running" the message privacy protections.

The reason that both attacks work is simple, on modern systems the attacker has as much --or more-- control on the supposadly trusted side of the security end point as they do in the untrusted communications channel.

That is we are stupid enough to put the security end point in a system we have no effective control over, whilst the attacker does have control. So message security is not possible in that usage configuration. That is the attacker can do a full end-run attack and get directly at the plaintext because there is no effective segregation in the likes of smart phones or other ICT that has a communications port the attacker has access to.

Thus the solution to your "Technology -v- legislation" foreboding is to put the security end point beyond the reach of the attacker... Plain and simple as the Victorians and earlier clearly understood and for some reason we appear to have forgotton.

Thus you need to consider any ICT equipment that is "connected" directly or indirectly to a communications port available by some method to an attacker as "untrusted". You also need to ensure that you can put the security end point beyond their ability to do an "end-run".

As a simple[1] example, you could use a paper and pencil One Time Pad encryption system to put the security end point beyond the reach of the untrusted communications channel. But you would also need to setup a place where you can use the OTP that the attacker can not end-run around by say having a small surveillance camera concealed in a ceiling mounted smoke detector, or wall mounted clock etc etc.

In essence the historical version of what became known as "air-gapping" in the latter half of the last century. However as I've also made clear air-gapping has been insufficient for the past couple of decades. I developed ways to cross air-gaps to show why voting machines were never going to be secure, and half a decade later Stuxnet should have made that totally clear to anybody who knows more about ICT than how to wave a mouse at an application. Which is why I now talk about the more restrictive "energy-gapping" that covers all aspects of unintentional eminations --TEMPEST-- and a large majority of susceptability or "fault injection" attacks which the likes of the NSA, GCHQ and other national Signals Intelligence (SigInt) agencies developed "secure cells" which now get called Sensitive Compartmented Information Facilities or SCIFs,

I've previously described on this blog what you need to do to set up both a semi-permanent cell which is in effect an extension of an EMC test "screened room". Also a very tempory system to stop audio/visuall end-run attacks, which can assembled / disassembled in seconds from unsuspicious items you would expect to find in nearly all homes (chair, table, foldaway laundry rack, blanket/ throw, cushions, glass fronted picture/mirror, angle poise lamp, table fan, battery radio etc).

[1] By saying simple I am removing other asspects you would need to consider such as what is called "KeyMan" or the managment, secure handeling and auditing of Keying Material (KeyMat).

PegrMarch 6, 2017 2:09 PM

Wait. You spoke at RSA? The company that accepted Federal money to weaken it's encryption? The company that allowed the root crypto key material of their customers go walking? And wanted to charge their customers to replace the key fobs that they themselves rendered worthless?

You spoke for them? Why would you do that?

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.