Security
in the Internet of Things

A bit of background and a short introduction.

Oktober 2015, Tobias Oberstein & Alexander Gödde, Crossbar.io

Part I: Background

Why is this important?

1. Privacy
   • Your devices don't just know what you did last summer...
   • ... but everything that you do!
2. Physical Safety
   • It's one thing when your PC crashes...
   • ... but another thing when your brakes fail while you're on the Autobahn!

... and this is not theoretical

Hackers were able to

• control the entertainment system
• track the position of the car remotely
• read the CAN bus
• control the engine, transmission, braking system

via the wireless network and without physical access to the car!

... to do this they needed to

• hack the Sprint cell network
• scan the network for cars
• brute-force the password for access to the entertainment system
• reprogram an embedded controller to get write access to the bus.

It took them years of tinkering - but then there are a lot of people out there with time on their hands!

FiatCrysler had to recall 1.4 million cars.

Some more IoT Hacks

• A Samsung smart fridge could be tricked into giving up a user's Google account credentials via wi-fi.
• A Samsung smart TV allowed remote access to its camera.
• A blast furnace couldn't be shut down in a German Steel Mill, damaging the furnace itself.
• A system of drug infusion pump was take off the market because of a remote control vulnerability.

This is not untypical

Some numbers from two separate studies: Of the IoT devices tested

• 50% didn't use transport encryption
• 60% didn' have secure update mechanisms
• 60% had cross-site scripting vulnerabilities in their Web interfaces
• 40% had no protection against replay attacks

What's the problem?

• Security for networked devices is hard.
• Time-to-market, features and price are immediate positives, while security problems are a distant negative.
• Companies from other industries are now doing networked software, and they use their engineering mindset.

Part II: Introduction

Security in IoT

• Attackers, Threat Models and Attack Surface
• Network Security for a simple IoT application
• Network Attack Surface Minimization

Attack and Attack Surface

• Attack (def.):
  "Any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself."
• Attack surface (def.):
  "Sum of all different entry points (= attack vectors) in a system or application that can be used to perform an attack."

Threat Model

• Threat Model (def.):
  abstraction of a particular set of security threats
• A threat model is a tool of thought (and communication) for developers, administrators and security researchers

Threat Model

• Example: "A chosen-plaintext attack is an attack model for cryptoanalysis which presumes that the attacker can obtain the ciphertexts for arbitrary plaintexts."
• Different alternative software designs, implementations and algorithms can be compared under a given threat model
• Threat models can be compared to each other: "A chosen-plaintext attack is more powerful than a known-plaintext attack, but less powerful than a chosen-ciphertext attack."

Useful Questions

Abstract definitions are nice, but here are some practical questions you might ask to better understand the threats you face:

• Who are the attackers?
• What do attackers want?
• What abilities do attackers have?

Who are the attackers?

• Security researchers & Hackers
• Script kiddies
• Criminals
• Competitors
• States & agencies
• Employees & Insiders
• One more: vendors!

What do attackers want?

• Control your systems
• Disturb the function
• They want your data
• Manipulate your data
• Ultimately: $$$ (most of the time)

What abilities might attackers have?

• Wiretap your network
• Selectively drop traffic from your network
• Selectively replay traffic on your network
• Inject arbitrary traffic into your network
• Flood your network and systems with noise
• Impersonate devices & systems
• Insert an USB stick into a system/device
• Physically destroy a device
• Talk an employee into disclosing his password
• ... (lots more) ...

A network threat model

We'll be looking at an IoT app under this threat model:
the (remote) attacker has TCP/IP level network access and is able to ..

• wiretap any traffic
• selectively drop traffic
• selectively replay traffic
• inject arbitrary traffic

A simple IoT app

We have a device with a LED and want to turn on/off the LED from a browser running anywhere.

This app will rock. Totally!

Btw: this is what people call "Command & Control"

So what's the big deal?

We need to talk to the device

More so: talk from the browser to the device

Alright, I can do that!

"Solution"

Let's just use HTTP, m'kay?

We are done!

Browsers, Web servers, languages, .. all talk HTTP.

Everyone knows HTTP. It's all there.

And to make it secure, we'll just add HTTPS (TLS).

That was easy. Let's go for a drink!

Wait a minute ..

It doesn't work

It's not secure

It doesn't scale

Network Issues

In practice, there is a double NAT'ted network often

Network Issues

The problem: most often, a device lacks a public routable IP (NAT) and lacks a public hostname also

Here are (non-working) approaches to fix:

• Port forwarding
• VPN
• IPv6

Network Issues

Alright, so how do I fix the network issue?

By asking the right question first;)

Because the bigger issue is: open ports are a security issue anyway!

Do you want a listening port
on your device in the first place?

HTTP Polling

Here is a HTTP based design with strictly outbound connections using "polling":

We are done!

The network issue is fixed. And it's secure.

Let's have that drink now!

Weell. Sorry to disturb, but there is a price.

Issues with HTTP Polling

Polling works "Ok", but comes at a price:

• Traffic volume
• Message latency

Traffic volume and message latency are two major performance metrics in IoT applications.

HTTP Polling Alternatives

So what's better than HTTP Polling?

• HTTP Long-polling
• WebSocket
• raw TCP?

A message router architecture

Here is our approach for building
scalable and secure IoT applications:

Principles of Network Attack Surface Minimization

Rule 1: There must not be any listening port on a device (all inbound connections must be blocked).

Rule 2: All application code must be separated from network server code.

Thanks for your attention!

Questions?