Subject: Re: [Ace] [Dtls-iot] Interesting article on IOT security from real world liability perspective

From: Carsten Bormann <[email-masked]>
Date: Sun, 12 Oct 2014 08:53:20 +0200

On 12 Oct 2014, at 07:11, StJohns, Michael <[email-masked]> wrote:

> http://money.cnn.com/2014/10/08/technology/security/internet-of-things-security/index.html?iid=HP_LN&hpt=hp_bn5

If you take the effort to look at the vulnerabilities reported, it is interesting to see that they are all exploiting the lame security model for today’s home networks: A single shared-key WiFi password that grants access to everything.

The LiFX vulnerability was caused by the light bulbs needing to tell each other that shared-key WiFi password over the (unsecured) 802.15.4 network.  (Well, it was dumb enough to communicate that key in an unsecured fashion, but the damage that LiFX could cause was much worse due to the sensitivity of the WiFi key.)

The Belkin camera vulnerability was caused by handing out the permanent keys for cloud access to the camera to anyone that had access to the WiFi network, even temporarily.  (That was probably considered OK because the shared-key protected home network is “secure”, no?)

Instead of having this simple-minded perimeter security, we need to move to real, authenticated authorization.  That’s what ACE is about.

Of course, as long as the IoT devices need the WiFi password to access the network, and other devices in the home rely on lame WiFi perimeter security, those other devices will remain vulnerable to any bugs in the IoT devices.  If you want to keep those lame other devices, the only solution here is to firewall them off.  (Using IPv6 for the IoT devices helps quite a way here.)

The next time you read one of those dime-a-dozen articles about “IoT security”, read closer and find out they are really a lament about today’s lame home network security model.

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Sun, 12 Oct 2014 16:11:21 -0400

> The next time you read one of those dime-a-dozen articles about “IoT security”, read closer and find out they are really a lament about today’s lame home network security model.

It's kind of interesting how different my take away was from yours. 
(And, yes, I did read the article and read it closely so please give me 
the benefit of the doubt that I knew what I was doing when I offered the 
article instead of suggesting I didn't understand what I was reading).

  I didn't/don't really care that a vulnerability was related to X or Y, 
but that the vendor knew that its scheme was weak and provided the 
product anyway.   The article wasn't about IOT security technology and I 
didn't present it as that (note the words "real world liability 
perspective" in the subject), but was an interesting look into the "ship 
or die" mentalities in a lot of product companies as it affects 
provision of good security technology in consumer products.

All of the products were/are considered "IOT" or IOT precursors. All of 
them were provided with about the cheapest security possible, at least 
partly because that security was in wide deployment. There's no evidence 
that the product companies actually looked at the threat models for the 
environment that their products were going to be in.

That's a continuing problem for companies, and sometimes a problem for 
the IETF and its working groups.

Later, Mike

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 13 Oct 2014 11:14:25 +0200

Hi Mike,

>>> http://money.cnn.com/2014/10/08/technology/security/internet-of-things-security/index.html?iid=HP_LN&hpt=hp_bn5

The article seems a bit sensation-seeking to me.. what exactly was your
point in posting it? If your intent is to point out that we need
security even for the smallest devices, I completely agree with you. If
you want to point out that it is easy to do security wrong, I also agree
with you.

I think one big problem in current developments in this area is that
there are no standardized security solutions for devices with strong
limitations in terms of processing power, storage space etc. Vendors
will come up with their own solutions which likely will have a lot of
security problems.

We could decide to refuse to develop protocols for this type of devices
and let those people go on with their own solution (I don't really
expect them to stop using those devices). Or we can design protocols
that are able to cope with the limitations of the devices and provide
the best possible security.

Best regards,
Steffi

---

From: Robert Cragie <[email-masked]>
Date: Mon, 13 Oct 2014 11:21:48 +0100

I think Mike's "ship or die" comment is very relevant. The problem with 
security is that it is not necessary to have it to function. A door 
without a lock is still a door. Therefore, the easiest corner to cut for 
a product is security as it is still possible to show products working 
without security in place. From that point of view, it is inevitable 
that early releases of products will have vulnerabilities, some of them 
significant. This will lead to sensationalist articles such as this, 
promoting the services of "security experts" who often have some snake 
oil solution which will cure everything.

However, I agree that the presence of standards and and subsequent 
multi-vendor support building it in to platforms, especially constrained 
platforms, will make it easier to produce products with "invisible 
security", i.e. baked in and virtually transparent to the actual 
function of the product. There is some way to go before we get there but 
that should be the goal and hopefully the ACE WG will help to achieve 
that goal.

Robert

On 13/10/2014 10:14 AM, Stefanie Gerdes wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Oct 2014 12:53:45 +0200

On 13 Oct 2014, at 12:21, Robert Cragie <[email-masked]> wrote:

> I think Mike's "ship or die" comment is very relevant. 

I completely agree.

Unfortunately, there is very little that we can do about this in the IETF.

I believe it is worth analyzing the unsavory situation we are in, to some greater detail.

— even if the companies wanted, they don’t have (and cannot afford) the engineering in house that could be tasked to create a secure product (there is one exception in the consumer electronics space, and their track record still isn’t exactly stellar)
— there is little economic incentive to be secure (no teeth in the product liability)
— sales and thus economic success is dominated by “ease of use”
  — and this is amplified by the need to minimize costly customer care contacts
— ease of use is dominated by
  — expectations of users (plug and play etc.)
    — you can’t actually be more secure in a way that causes hassle that users don’t expect
  — interoperability with what’s already there
    — which includes deployed systems with abysmal security
      — that might damage the security of the IoT gear if it relies on that
      — or bugs/unforeseen interactions of the IoT gear might damage the “security” of deployed systems

It is very hard to secure home IoT if that needs to plug into and interact with other networked home gear in its current insecure state.  My only hope is that if IoT gear can be made to lead in usable security, that might shift expectations.  It seems we’ll have to do some of the engineering here that the gear makers can’t.

We also need to spend more time pointing out that, if it isn’t usably secure, it’s *not* IoT.

Grüße, Carsten

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 14 Oct 2014 10:18:52 +0900

I agree that the article is one of dime-a-dozen articles while such security vulnerabilities were happened due to the “ship or die” mentalities, which are needed these days especially to startups. I bet that such security vulnerabilities will be continuously reported and the IETF cannot help much for solving those things happen. The IETF is just one of standardization development organizations.

J.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: [email-masked]
#webpage: https://sites.google.com/site/hurryon

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 13 Oct 2014 22:08:07 -0400

On Mon, Oct 13, 2014 at 6:53 AM, Carsten Bormann <[email-masked]> wrote:

> — even if the companies wanted, they don’t have (and cannot afford) the
> engineering in house that could be tasked to create a secure product (there
> is one exception in the consumer electronics space, and their track record
> still isn’t exactly stellar)

We should do what we can within the scope of work for ACE.  When we get
further into this work, having some open source implementations could
help.  The hard part may be reaching the vast number of products for which
these solutions might apply so their engineers are aware of the work and
other efforts they should be leveraging.  We can't really worry about the
marketing, but there is a real need to improve the state of security for
IoT and I look forward to seeing what this team does to help.

Does this article and discussion influence the use cases?  I think that's
where we are at right now and contributions are welcome to improve,
discuss, or add use cases.

Thanks,
Kathleen

>
> It is very hard to secure home IoT if that needs to plug into and interact
> with other networked home gear in its current insecure state.  My only hope
> is that if IoT gear can be made to lead in usable security, that might
> shift expectations.  It seems we’ll have to do some of the engineering here
> that the gear makers can’t.
>

-- 

Best regards,
Kathleen