towards a secure internet of thingsgr/uploads/percom-2018-k1.pdf · data security: research and...

Towards a Secure Internet of Things

Philip LevisStanford University

Keynote TalkIEEE International Conference on Pervasive Computing and Communication

March 20, 2018

1

The Internet of Things (IoT)

2

A Security Disaster

31http://fortifyprotect.com/HP_IoT_Research_Study.pdf

• HP conducted a security analysis of IoT devices1

▶ 80% had privacy concerns▶ 80% had poor passwords▶ 70% lacked encryption▶ 60% had vulnerabilities in UI▶ 60% had insecure updates

This Talk

• Technology trends: why today?

• Security: why is it so hard?

• Research: what we’re doing

4

515.iii.2005 Stanford Interview Talk 2

The EmNets Vision•  “Information technology (IT) is on the verge of

another revolution… The use of EmNets [embedded networks] throughout society could well dwarf previous milestones.” 1

•  “The motes [EmNet nodes] preview a future pervaded by networks of wireless battery-powered sensors that monitor our environment, our machines, and even us.” 2

1 National Research Council. Embedded, Everywhere, 2001.2 MIT Technology Review. 10 Technologies That Will Change the World, 2003.

Two Game-Changers

• ARM Cortex M series▶ First released 2004▶ Ultra-low power 32-bit processor▶ 8-96kB of RAM, 64-512kB code flash▶ Sleep currents recently dropped <1µA

• Bluetooth Low Energy▶ First released in 2006▶ Send a 30 byte packet once per second, last

for a year on a coin cell battery▶ Support was weak until Apple incorporated

into iBeacon, now all major smartphones include it

6

Example Part: nRF51422

• Cortex M0+ with integrated 2.4GHz transceiver▶ Supports Bluetooth Low Energy▶ Two models: 32kB/256kB or 16kB/128kB

• DigiKey cost for 3,000: $1.88

7

Two Game-Changers

• ARM Cortex M series▶ First released 2004▶ Ultra-low power 32-bit processor▶ 8-96kB of RAM, 64-512kB code flash▶ Sleep currents recently dropped <1µA

• Bluetooth Low Energy▶ First released in 2006▶ Send a 30 byte packet once per second, last

for a year on a coin cell battery▶ Support was weak until Apple incorporated

into iBeacon, now all major smartphones include it

8

Typical Hardware Designsimix, Stanford/Berkeley

• Imix development board,many debugging pinouts

• Multi-core system▶ 802.15.4 radio▶ Cortex-M4 application MCU▶ Cortex-M0 BLE SoC

9

• Squall: ultra-low cost embedded device▶ nRF51822 BLE/CortexM0+ and a few expansion headers

10

Typical Hardware DesignsSquall, University of Michigan

Why Today?

1. Chips and radios are now low power enough to enable long lived, low data rate devices

2. BLE enables phones to control and collect data from IoT devices

11

This Talk

• Technology trends: why today?

• Security: why is it so hard?

• Research: what we’re doing

12

Internet(s) of Things

13

IndustrialAutomation

Thousands/personThousands/personControlled Environment

High reliabilityHigh reliabilityControl networks

Industrial requirements

WirelessHART, 802.15.46tsch, RPL

IEEE/IIC/IETF

Internet(s) of Things

14

Home AreaNetworksHundreds/personHundreds/person

Uncontrolled EnvironmentUnlicensed spectrumUnlicensed spectrum

ConvenienceConsumer requirements

ZigBee, Z-WaveZigBee, Z-Wave6lowpan, RPL6lowpan, RPL

IETF/ZigBee/private

IndustrialAutomation

Thousands/personThousands/personControlled Environment

High reliabilityHigh reliabilityControl networks

Industrial requirements

WirelessHART, 802.15.46tsch, RPL

IEEE/IIC/IETF

Internet(s) of Things

15

Personal AreaNetworks

Tens/personTens/personPersonal environmentUnlicensed spectrumUnlicensed spectrum

InstrumentationFashion vs. function

Bluetooth, BLE3G/LTE

3GPP/IEEE

Home AreaNetworksHundreds/personHundreds/person

Uncontrolled EnvironmentUnlicensed spectrumUnlicensed spectrum

ConvenienceConsumer requirements

ZigBee, Z-WaveZigBee, Z-Wave6lowpan, RPL6lowpan, RPL

IETF/ZigBee/private

IndustrialAutomation

Thousands/personThousands/personControlled Environment

High reliabilityHigh reliabilityControl networks

Industrial requirements

WirelessHART, 802.15.46tsch, RPL

IEEE/IIC/IETF

Internet(s) of Things

16

NetworkedDevices

Tens/personTens/personUncontrolled Environment

Unlicensed spectrumUnlicensed spectrumConvenience

Powered

WiFi/802.11TCP/IP

IEEE/IETF

Personal AreaNetworks

Tens/personTens/personPersonal environmentUnlicensed spectrumUnlicensed spectrum

InstrumentationFashion vs. function

Bluetooth, BLE3G/LTE

3GPP/IEEE

Home AreaNetworksHundreds/personHundreds/person

Uncontrolled EnvironmentUnlicensed spectrumUnlicensed spectrum

ConvenienceConsumer requirements

ZigBee, Z-WaveZigBee, Z-Wave6lowpan, RPL6lowpan, RPL

IETF/ZigBee/private

IndustrialAutomation

Thousands/personThousands/personControlled Environment

High reliabilityHigh reliabilityControl networks

Industrial requirements

WirelessHART, 802.15.46tsch, RPL

IEEE/IIC/IETF

eMbeddeddevices

17

IoT: MGC Architecture

6lowpan,ZigBee,ZWave,

Bluetooth,WiFi,

WirelessHART

eMbeddeddevices

Gateways

18

IoT: MGC Architecture

6lowpan,ZigBee,ZWave,

Bluetooth,WiFi,

WirelessHART

3G/4G,TCP/IP

eMbeddeddevices

GatewaysCloud

19

IoT: MGC Architecture

6lowpan,ZigBee,ZWave,

Bluetooth,WiFi,

WirelessHART

3G/4G,TCP/IP

eMbeddeddevices

GatewaysCloud

20End application

IoT: MGC Architecture

6lowpan,ZigBee,ZWave,

Bluetooth,WiFi,

WirelessHART

Secure Internet of Things 23

Obj-C/C++, Java, Swift, Javascript/HTML

embedded C(ARM, avr, msp430)

ZigBee,ZWave,

Bluetooth,WiFi

3G/4G,TCP/IP

Ruby/Rails,Python/Django,J2EE, PHP, Node.js

IoT Security is Hard

• Complex, distributed systems▶ 103-106 differences in resources across tiers▶ Many languages, OSes, and networks▶ Specialized hardware

• Just developing applications is hard

• Securing them is even harder▶ Enormous attack surface▶ Reasoning across hardware, software, languages, devices, etc.▶ What are the threats and attack models?

• Valuable data: personal, location, presence

• Rush to development + hard ➔ avoid, deal later

21

What We’re Doing

22

SITP

• Secure Internet of Things Project▶ 5 year project (in year 4)▶ 13 faculty collaborators▶ 3 universities: Stanford, Berkeley, and Michigan

• Rethink IoT systems, software, and applications from the ground up

• Make a secure IoT application as easy as a modern web application

23

Dawson EnglerStanfordSoftware

24

Philip LevisStanford

Embedded Systems

Mark HorowitzStanford

Hardware

Zakir DurumericStanford

Internet Security

Dan BonehStanford

Cryptography

Keith WinsteinStanford

Networks

Prabal DuttaBerkeley/Michigan

Embedded Hardware

David MazièresStanfordSecurity

Björn HartmannBerkeley

Prototyping

Raluca Ada PopaBerkeleySecurity

Steve EglashStanford

Executive Director

Philip LevisStanfordFaculty Director

Who?

David CullerBerkeley

Low Power Systems

Peter BailisStanford

Databases

Two Goals

25

1. Data security: research and define new cryptographic computational models for secure data analytics and actuation on enormous streams of real-time data from embedded systems.

2. System security: Research and implement a secure, open source framework that makes it easy to quickly build Internet of Things applications that use these new computational models.

Two Goals

26

1. Data security: research and define new cryptographic computational models for secure data analytics and actuation on enormous streams of real-time data from embedded systems.

2. System security: Research and implement a secure, open source framework that makes it easy to quickly build Internet of Things applications that use these new computational models.

A Few Projects

• Beetle and Bark: connecting the Internet of Things

• Tock: a secure embedded operating system

27

The Internet of Things

28

Internet

The Reality

29

BLE Is the Problem

30

socket

TCP/IP

Beetle• Virtualizes BLE devices

• Multiple applications can use a single peripheral

• Peripherals can communicate with one another

• Security policies for peripheral management

• Can now build previously impossible applications▶ Smart watch opens smart lock▶ Energy monitor application▶ Decouple logging and UI

31

Beetle!

OS!

BLE!

Application!

Application!

Virtual Device!

Controller!

Peripherals!

HAT!

Virtual Devices

• Beetle allows any process to present virtual devices▶ Virtual devices provide the standard Generic Attribute (GATT)

interface to attributes: Notify, Read, Write, etc.▶ Many processes can access a virtual device

• Gateway (controller) re-advertises profiles to its peripherals through handle address translation (HAT)▶ Phone connects to a lock, advertises that it is now a lock

• Software can provide arbitrary profiles (e.g., bridge to larger Internet)

32

T

W

W

P

T

P

Security Policies: Bark

• Default-off communication▶ IoT devices are different, require narrow communication▶ Explicitly enable communication

• Five questions: who, what, where, how, when?

• Map these to underlying network primitives

Allow 𝒑𝟏, at 𝒈𝟏, to perform 𝒂 on 𝑹 of 𝒑𝟐, at 𝒈𝟐, when ⊤ = (𝒄𝟏∧ 𝒄𝟐) ∨ 𝒄𝟑 …

Subject{(p1, g1)} Action{a}

Object{(R, p2, g2)} Conditions{(c1∧ c2) ∨ c3 …}

who{𝑝1}

who{𝑝2}

where{𝑔1}

where{𝑔2}what{𝑅}

how{𝑎}

when{𝑐1} when{𝑐2} when{𝑐3}

33

Example Rules

34

Allow the bedroom switch to changeon/off of bedroom lights at any time

Who{Bedroom Switch}

Who{Group(Bedroom Lights)}

Subject{(Bedroom Switch, *[all])} Action{BLE/GATT write}

How{BLE/GATT write}

What{UUID(on/off)} When{Cron(* * * * *)}

Object{(UUID(on/off), Group(Bedroom Lights), *[all])} Conditions{Cron(* * * * *)}

Allow anyone, from near the home, to see/changelock/unlock of front door lock when homeowner allows it

Who{front door lock}

Who{*[one]}

Subject{(*[one], Group(home gateways)} Action{BLE/GATT read/write}

How{BLE/GATT read/write}

What{UUID(lock/unlock)} When{AdminAuthorization(homeowner)[30s]}

Object{(UUID(lock/unlock), front door lock), *[all])} Conditions{AdminAuthorization(homeowner)[30s]}

Where{Group(home gateways)}

A Few Projects

• Beetle and Bark: connecting the Internet of Things

• Tock: a secure embedded operating system

35

Challenges

• Modern software development wants to incorporate libraries, drivers, external code

• Want code to execute safely▶ Driver bug can’t crash device▶ Security flaw in external code can’t compromise whole system

• Microcontrollers lack traditional isolation mechanisms▶ No virtual memory▶ No segmentation

• Microcontrollers are memory-constrained▶ 16-64kB, 12-80MHz CPU▶ Can’t have many execution stacks, exhaustion easy

36

Tock Operating System

• Safe, multi-tasking operating system for memory-constrained devices

• Core kernel written in Rust, a safe systems language▶ Small amount of trusted code (can do unsafe things)

- Rust bindings for memory-mapped I/O- Core scheduler, context switches

• Core kernel can be extended with capsules▶ Safe, written in Rust▶ Run inside kernel

• Processes can be written in any language (asm, C) ▶ Leverage Cortex-M memory protection unit (MPU)▶ User-level, traps to kernel with system calls

37

Tock Architecture

38

HAL Scheduler Config

SPI

I2C

GPIO

Console

UART

Timer

Core kernel(Trusted)

Capsules(Untrusted)

Proc

esse

s(A

ny la

ngua

ge)

Kern

el(R

ust)

…heapstack

textdata

grant

heapstack

textdata

grant

RAM

Flash

ProcessAccessible

Memory

Rust Safety

• Tackles two problems:▶ Thread safety (concurrent access)▶ Memory safety (address contains proper type)

• Rule 1: a memory location can have one read/write pointer or multiple read-only pointers▶ mutable references and references in Rust parlance

• Rule 2: a reference can only point to memory that is assured to outlive the reference▶ prevents dangling pointers

39

Rust Rule

• A memory location can have one read/write pointer or multiple read-only pointers▶ mutable references and references in Rust parlance

40

let mut x = 5;let y = &x;let z = &x;

let mut x = 5;let y = &mut x;let z = &x;

let mut x = 5;let y = &mut x;let z = &mut x;

OK No No

Why

41

enum NumOrPointer { Num(u32), Pointer(&'static mut u32)}

// n.b. illegal example let external : &mut NumOrPointer; match external { &mut Pointer(ref mut internal) => { // This would violate safety and // write to memory at 0xdeadbeef *external = Num(0xdeadbeef); *internal = 12345; }, ... }

Problem 1: Events

• Often want to register multiple event callbacks on a single structure▶ E.g., networking stack has packet reception and timers

• Each callback needs a mutable reference

42

6lowpantimer

RF233

timeout

recv

Problem 2: System Calls

• System calls need to dynamically allocate memory▶ Create a timer, kernel needs to keep timer’s state▶ Enqueue a packet to send, kernel needs reference to packet

• Kernel can’t dynamically allocate memory!▶ Otherwise a process can exhaust kernel memory▶ Fragmentation

43

Events: Insight

• If we can ensure memory outlives reference, then multiple mutable references can be safe

• Rule: if there is a reference to memory block M, there cannot be any references inside M

44

6lowpan

timer

RF233

timeout

recv

6lowpan

timer

RF233

timeout

recv

Safe Unsafe

System Call Insight

45

HAL Scheduler Config

SPI

I2C

GPIO

Console

UART

Timer

Core kernel(Trusted)

Capsules(Untrusted)

Proc

esse

s(A

ny la

ngua

ge)

Kern

el(R

ust)

…heapstack

textdata

grant

heapstack

textdata

grant

RAM

Flash

ProcessAccessible

Memory

System Call Insight

HAL Scheduler Config

���

���

����

����� �

��

����

Core kernel(Trusted)

Capsules(Untrusted)

Proc

esse

s(A

ny la

ngua

ge)

Kern

el(R

ust)

…heapstack

textdata

grant

heapstack

textdata

grant

RAM

Flash

ProcessAccessible

Memory

grantgrant• Processes given

block of memory

• Dynamically allocated when process loaded

• Kernel can allocate memory from process

• But references can’t escape…

46

Mechanism: MapCells

• Rust-enforced encapsulation:cannot access internal fields

• Code must copy in and out▶ Expensive!▶ Introduce new types that use closures

to allow callers to access internal state

• Safe to have multiple referencesto a container

• Can pass a closure into the cell

47

sam4l::spi::Spi

regs

callback

dma_read

dma_write

reading

writing

read_buffer

write_buffer

dma_length

grant container

callerfunction

self.tx_client.get().map(|c| { c.send_done(buf.unwrap(), ReturnCode::SUCCESS); });

Process Grant Regions

• Kernel can allocate objects from the grant block

• References to objects cannot escape the block▶ Process failure/crash does not lead to dangling pointers

• Users pass a function to the container with enter

48

grant container

callerfunction

self.apps.enter(appid, |app, _| { app.read_buffer = Some(slice); app.read_idx = 0; 0}).unwrap_or(-1)

Tock Status

• Support for three platforms▶ imix: multicore development board▶ signpost: extensible community sensing platform▶ squall/nRF51: BLE/CortexM0 SoC▶ http://tockos.org▶ https://github.com/helena-project/tock

• Increasing community support▶ launchxl platform▶ EK-TM4C1294X (launchpad)▶ nRF52

• Other platforms: security USB devices, etc.

49

Why Now?

• Technology has just reached the tipping point▶ BLE, iBeacon▶ Cortex M series▶ Sensors▶ Harvesting circuits

• We've been waiting▶ Leaders in prototyping, cryptographic computation, IoT networking,

secure systems, analytics, and hardware design▶ What are the threats? Application attackers?

• But it's still early enough▶ Most big applications haven't been thought of yet▶ Let's not repeat the web (as good as it is for publications)

50

Securing the Internet of Things

• Secure Internet of Things Project▶ 5 year project (starting now)▶ 12 faculty collaborators▶ 3 universities: Stanford, Berkeley, and Michigan

• Rethink IoT systems, software, and applications from the ground up▶ Beetle communication and Bark policies▶ Tock, a secure embedded operating system

• Make a secure IoT application as easy as a modern web application

51

Dawson EnglerStanfordSoftware

52

Philip LevisStanford

Embedded Systems

Mark HorowitzStanford

Hardware

Zakir DurumericStanford

Internet Security

Dan BonehStanford

Cryptography

Keith WinsteinStanford

Networks

Prabal DuttaBerkeley/Michigan

Embedded Hardware

David MazièresStanfordSecurity

Björn HartmannBerkeley

Prototyping

Raluca Ada PopaBerkeleySecurity

Steve EglashStanford

Executive Director

Philip LevisStanfordFaculty Director

Thank you!

David CullerBerkeley

Low Power Systems

Peter BailisStanford

Databases

Questions

53