1

Security First: IoT

Hugo Fiennes, Co-founder & CEO, electric imp

Security First

When you’re making a connected product, or a service that deals with connected products and their data, you need to consider security before any other aspect.

Including privacy.

Without security, there cannot be privacy.

2

Why? This sort of thing is bad…

3

Really, hackers are only just getting started with the IoT…

4

0

5

10

15

20

defcon 18 defcon 19 defcon 20 defcon 21 defcon 22

Number of IoT related sessions at thelast 5 DEFCON conferences

iot/scada car consumer embedded

Why are there so many insecure connected products?

• Security is not an area most product companies have experience with

• They need to find and hire appropriate experts…• …and empower them to do possibly costly things with no immediate ROI

• Product companies usually work serially:

• Make product n, test/debug/optimize, ship• Make product n+1, test/debug/optimize, ship• Make product n+2, test/debug/optimize, ship

5

Security is iterative, never “done”

• Build/ship/forget only works when products don’t need to be updated

• Generally, a manufacturer will only see a product again if it fails.• The entire engineering function is often not architected for sustaining engineering.

• It fails to work with connected products

• They do not ship into a static world• Threats and exploits change and evolve over time• The customer expects – and trusts the brand – to provide the same quality experience

long after the product was purchased

6

Dystopian future: consumer IoT in 5 years

• Your home has become a wretched hive of scum and villainy• We must be cautious

• Those cheap chinese power monitors you bought from eBay will be sending 419 spam.

• Your dishwasher will be locked in a firmware upgrade loop.• Your lights can only be controlled by the phone you stopped

using 4 years ago.

7

Hmm.

So that was depressing.

What can be done?

8

The first rule of IoT (club)…

Products must be able to be upgraded securely, without end-user intervention.

9

(see: Belkin WeMo, Dlink,Almost every home router…)

Second rule: start at product definition

• Feature set• How can each feature be implemented securely, without breaking

either the functionality or the user experience?

• Setup process• How can a device be provisioned securely, and the ownership of the

device be established?

• Data flows• What is the appropriate level of protection for data flowing both

from and to the device?

10

Third rule: budget for it

• Security maintenance is not free• It’s better than the alternative, though• Damage to your reputation is hard to price.

• You need to be able to provide updates for the product lifetime• This means being able to regression test firmware and products that may have

been out of production for many years.• This requires quite a bit of development discipline.• Ideally, having a way to safely EOL a product is good

11

Security and things: Threat model

• What attacks am I concerned about?• Physical: when attacker has physical access to the device• Local: when attacker has direct network access to the device• MITM: when attacker is between device and network• Server: when attacker targets the host service

• What areas are high vulnerability?• Configuration/setup/provisioning modes are often less tested• Remnants of factory test modes are often insecure

• How much cost can my design bear?• There are always trade-offs

12

Security and things: Attack surface

• The attack surface is the sum of all the possible vectors that could be used to compromise security• The smaller the attack surface, the easier it is to secure a product

• A typical attack surface consists of several areas:• Hardware: JTAG, external memories, debug console, ISP/test connectors• Software: buffer overruns in bootloader, malformed TCP packets, illegal TLS

negotiations or options, diagnostic modes, local control interfaces• Network: malformed link packets, insufficient entropy for key generation,

diagnostic/setup ports, simplistic authentication schemes, etc

• Once an entry point has been secured, the size of the attack surface is often irrelevant

13

Example: Physical security

Nothing is totally secure. Your job is to pick an appropriate level of paranoia.

This often does not need to be an expensive effort.

14

Level Cost per unit

Cost to hack

Notes

Zero $0.00 $0 Insecure bootloader, exposed JTAG or console UART, etc

One $0.00 $1000+ Remove JTAG/console test points, remove your backdoors

Two $0.25+ $100,000+ JTAG disabled with OTP fuse, secure bootloader, memory protection deployed appropriately

Three $0.50+ ??? Unique, per-device authentication/encryption

Security and things: Replicability

• The most damaging hacks are the ones that can be replicated easily

• It can be cost-prohibitive to prevent attackers with physical access from at least compromising the normal operation of a system

• …but if an attacker with physical access can find a weakness and use it to devise an attack that does not require physical access, that’s bad.

• For example:

• Network attacks (buffer overflows, malformed data, etc)• MITM attacks (snoop on or alter traffic to/from devices)• Leaks of secrets shared by all devices (eg symmetric encryption keys)

15

The last rule: Build, or buy, a platform

Separating the application from the platform is a good thing.

The platform remains common across products, reducing the cost of maintenance for each product and justifying more work on hardening the attack surface.

This also insulates the application from the hardware, allowing consistency in development even for product refreshes and cost reductions.

16

Where What

Application Application-specific logic, UI

Platform Network stack, OS, drivers

Hardware Physical security

With a good architecture,most of the security work

happens here

Contractual Electric Imp mention

Electric Imp is a cloud platform for people to build connected devices with.

We deal with things like long-term maintenance, security, scalability, compatibility, link maintenance, cloud-based middleware, stupid routers and hardware abstraction.

We work with people who want to build great connected products or services, but who rightly believe that spending all their time debugging networking and fixing security holes isn’t a good commercial strategy.

17

Q&A

(btw, I have slides from ARM techcon if you want a much more technical view –please ask!)

ps: we are hiring…

18

www.electricimp.com

connectivity made simple

19