in the Internet of Things
A bit of background and a short introduction.
Oktober 2015, Tobias Oberstein & Alexander Gödde,
Why is this important?
Your devices don't just know what you did last summer...
... but everything that you do!
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.
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 (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
- 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."
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
- 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!
"We have a device with a LED and want to turn on/off the LED from a browser running anywhere."
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!
Let's just use HTTP, m'kay?
We are doing a HTTP/POST request to
with a POST body either
On the device we have a HTTP server listening on port 80.
The Web server runs a small script that controls the LED.
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
In practice, there is a double NAT'ted network often
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:
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!
We won't touch even more security issues like: how are you going to distribute your TLS certificates for all the device Web servers? etc etc
Do you want a listening port
on your device in the first place?
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
- 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.
Is this a silver bullet? Will it bring peace on earth?
Sorry, nope. But it's a good approach to start with.
Thanks for your attention!