View
986
Download
51
Tags:
Embed Size (px)
Citation preview
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
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
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