Security in the Internet of Things

Yes, You need to worry *now*

Created by Jeffrey I. Schiller February 22, 2014

Introduction

• No One ever wants to do Security
• Its a “Negative Deliverable”
• You don’t know when you have it, only when you have lost it.
• Its a cost, generates no revenue
• What me worry, no one is attacking!

Security from the Beginning

• If you ignore security you make design decisions that make adding it later hard.
• I have seen this time and time again.
  • Email, Voice of IP
• “Bad Guys” only show up after significant deployment

Understand Your Threats

• What is your “Threat Model”
• What do the bad guys want to do
• There are some things that everyone wants to do with an Internet connected device
  • Botnets anyone!
• Beyond that it is application specific
• Beware the Hacktivist

Things have a Hard Time

• They are not computers
• People don’t think of them as computers
• Will they get patches or updates?
  • Probably not...
• Need to securely Update Them
• You won’t have access, but your adversaries will!
• Most devices will be behind a NAT
• One that you cannot penetrate but the bad guys can

What to do

• You will need Internet/Security experts
• And I don’t mean someone who took the 2 week course
• Plan on updating firmware
• Software should be in mostly read-only memory
• Except for updating
• Android is a good model to look at
• You will need a good source of entropy

Software Update

• Device has to poll
• Need to Authenticate New Update
• Solution: Digitally Sign Update
• Problem: Protecting the Private Signing Key

Protecting the Key: FAIL

• Most Software is stored in a VC Repository (Git, Mercurial...)
• Typically there is an automated or CI build server
• To get Signed Binaries, you need the private key
• So too many organizations put the signing key in the Repository
• “Three can keep a secret if two of them are dead!” –Benjamin Franklin
• Keys in Repositories *always* leak
  • Holy GitHub Batman!
• Production Staff often are not security savy

Neat Trick from Bitcoin

• Don’t embed public key in software
• Embed the hash (or two) of the public key
• Distribute the Public Key with the next signed update
• Update the Hashed Key to a new one when updating
• Attacker has to first reverse a hash before attacking the Public Key System

Questions?