Though the potential of the IoT is vast, adoption can easily be curtailed by security worries. No company wants their products to be a victim of a hack, yet many do not appear to consider security as a primary driver of design decisions. This presentation will look at IoT security and describe what product designers – regardless of platform – need to be aware of if they want to build a secure and successful device. IoT security encompasses requirements that are new for many product designers – such as provisioning, authentication, OTA upgrades and link encryption – and weaknesses in any one could potentially be used to compromise the security of the end product. From physical attacks to analysis of communications channels, there are many possible attack vectors that need to be considered. From hacked routers to refrigerators sending spam email, there have been a lot of scary news stories about Internet of Things (IoT) security, or lack of it. According to the 2014 Hewlett-Packard Internet of Things Research Study, 70% of Internet connected devices they surveyed didn’t even use encrypted network connections. The US Federal Trade Commission (FTC) recently weighed in on the issue too, releasing a report that outlines potential IoT security risks, ranging from unauthorized access and misuse of personal information, to facilitation of attacks on other systems and risks to personal safety.

1. 1
Security First: IoT
Hugo Fiennes, Co-founder & CEO, electric imp

2. 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

3. Why? This sort of thing is bad…
3

4. 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 the
last 5 DEFCON conferences
iot/scada car consumer embedded

5. 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

6. 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

7. 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

8. Hmm.
So that was depressing.
What can be done?
8

9. 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…)

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. Q&A
(btw, I have slides from ARM techcon if you want a much more technical view –
please ask!)
ps: we are hiring…
18

19. www.electricimp.com
connectivity made simple
19