Towards a Secure Internet of Things

Transcription

1 Towards a Secure Internet of Things Philip Levis Stanford University Keynote Talk IEEE International Conference on Pervasive Computing and Communication March 20,

2 The Internet of Things (IoT) 2

3 A Security Disaster HP conducted a security analysis of IoT devices 1 80% had privacy concerns 80% had poor passwords 70% lacked encryption 60% had vulnerabilities in UI 60% had insecure updates 1http://fortifyprotect.com/HP_IoT_Research_Study.pdf 3

4 This Talk Technology trends: why today? Security: why is it so hard? Research: what we re doing 4

5 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 batterypowered sensors that monitor our environment, our machines, and even us. 2 1 National Research Council. Embedded, Everywhere, MIT Technology Review. 10 Technologies That Will Change the World, iii.2005 Stanford Interview Talk 2 5

6 Two Game-Changers ARM Cortex M series First released 2004 Ultra-low power 32-bit processor 8-96kB of RAM, kB 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

7 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

8 Two Game-Changers ARM Cortex M series First released 2004 Ultra-low power 32-bit processor 8-96kB of RAM, kB 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

9 Typical Hardware Designs imix, Stanford/Berkeley Imix development board, many debugging pinouts Multi-core system radio Cortex-M4 application MCU Cortex-M0 BLE SoC 9

10 Typical Hardware Designs Squall, University of Michigan Squall: ultra-low cost embedded device nrf51822 BLE/CortexM0+ and a few expansion headers 10

11 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

12 This Talk Technology trends: why today? Security: why is it so hard? Research: what we re doing 12

13 Internet(s) of Things Industrial Automation Thousands/person Controlled Environment High reliability Control networks Industrial requirements WirelessHART, tsch, RPL IEEE/IIC/IETF 13

14 Internet(s) of Things Industrial Automation Thousands/person Controlled Environment High reliability Control networks Industrial requirements WirelessHART, tsch, RPL IEEE/IIC/IETF Home Area Networks Hundreds/person Uncontrolled Environment Unlicensed spectrum Convenience Consumer requirements ZigBee, Z-Wave 6lowpan, RPL IETF/ZigBee/private 14

15 Internet(s) of Things Industrial Automation Thousands/person Controlled Environment High reliability Control networks Industrial requirements WirelessHART, tsch, RPL IEEE/IIC/IETF Home Area Networks Hundreds/person Uncontrolled Environment Unlicensed spectrum Convenience Consumer requirements ZigBee, Z-Wave 6lowpan, RPL IETF/ZigBee/private Personal Area Networks Tens/person Personal environment Unlicensed spectrum Instrumentation Fashion vs. function Bluetooth, BLE 3G/LTE 3GPP/IEEE 15

16 Internet(s) of Things Industrial Automation Home Area Networks Personal Area Networks Networked Devices Thousands/person Controlled Environment High reliability Control networks Industrial requirements Hundreds/person Uncontrolled Environment Unlicensed spectrum Convenience Consumer requirements Tens/person Personal environment Unlicensed spectrum Instrumentation Fashion vs. function Tens/person Uncontrolled Environment Unlicensed spectrum Convenience Powered WirelessHART, tsch, RPL IEEE/IIC/IETF ZigBee, Z-Wave 6lowpan, RPL IETF/ZigBee/private Bluetooth, BLE 3G/LTE 3GPP/IEEE WiFi/ TCP/IP IEEE/IETF 16

17 IoT: MGC Architecture embedded devices 6lowpan, ZigBee, ZWave, Bluetooth, WiFi, WirelessHART 17

18 IoT: MGC Architecture embedded devices 6lowpan, ZigBee, ZWave, Bluetooth, WiFi, WirelessHART Gateways 18

19 IoT: MGC Architecture embedded devices 6lowpan, ZigBee, ZWave, Bluetooth, WiFi, WirelessHART Gateways Cloud 3G/4G, TCP/IP 19

20 IoT: MGC Architecture embedded devices 6lowpan, ZigBee, ZWave, Bluetooth, WiFi, WirelessHART Gateways Cloud 3G/4G, TCP/IP End application 20

21 IoT Security is Hard Complex, distributed systems 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 embedded C (ARM, avr, msp430) ZigBee, ZWave, Bluetooth, WiFi 3G/4G, TCP/IP Ruby/Rails, Python/Django, J2EE, PHP, Node.js Obj-C/C++, Java, Swift, Javascript/HTML Secure Internet of Things 23 Rush to development + hard avoid, deal later 21

22 What We re Doing 22

23 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

24 Who? Philip Levis Stanford Embedded Systems Mark Horowitz Stanford Hardware Zakir Durumeric Stanford Internet Security Dan Boneh Stanford Cryptography Dawson Engler Stanford Software Keith Winstein Stanford Networks Peter Bailis Stanford Databases David Mazières Stanford Security Björn Hartmann Berkeley Prototyping Raluca Ada Popa Berkeley Security Prabal Dutta Berkeley/Michigan Embedded Hardware David Culler Berkeley Low Power Systems Steve Eglash Stanford Executive Director Philip Levis Stanford Faculty Director 24

25 Two Goals 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. 25

26 Two Goals 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. 26

27 A Few Projects Beetle and Bark: connecting the Internet of Things Tock: a secure embedded operating system 27

28 The Internet of Things Internet 28

29 The Reality 29

30 BLE Is the Problem socket TCP/IP 30

31 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 Controller! Peripherals! HAT! Application! Virtual Device! Beetle! OS! BLE! Application! 31

32 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) W P T T P W 32

33 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 Subject{(p 1, g 1 )} Action{a} who{p 1 } Allow p 1, at g 1, to perform a on R of p 2, at g 2, when = (c 1 c 2 ) c 3 what{r} who{p 2 } where{g 2 } where{g 1 } how{a} when{c 1 } when{c 2 } when{c 3 } Object{(R, p 2, g 2 )} Conditions{(c 1 c 2 ) c 3 } 33

34 Example Rules Subject{(Bedroom Switch, *[all])} Who{Bedroom Switch} Action{BLE/GATT write} How{BLE/GATT write} Allow the bedroom switch to change on/off of bedroom lights at any time What{UUID(on/off)} Who{Group(Bedroom Lights)} When{Cron(* * * * *)} Object{(UUID(on/off), Group(Bedroom Lights), *[all])} Conditions{Cron(* * * * *)} Subject{(*[one], Group(home gateways)} Action{BLE/GATT read/write} Who{*[one]} Where{Group(home gateways)} How{BLE/GATT read/write} Allow anyone, from near the home, to see/change lock/unlock of front door lock when homeowner allows it What{UUID(lock/unlock)} Who{front door lock} When{AdminAuthorization(homeowner)[30s]} Object{(UUID(lock/unlock), front door lock), *[all])} Conditions{AdminAuthorization(homeowner)[30s]} 34

35 A Few Projects Beetle and Bark: connecting the Internet of Things Tock: a secure embedded operating system 35

36 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

37 Tock Operating System Safe, multi-tasking operating system for memoryconstrained 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

38 Tock Architecture grant grant Processes (Any language) heap stack data RAM heap stack data Process Accessible Memory text Flash text Kernel (Rust) SPI I2C UART Console GPIO Timer HAL Scheduler Config Capsules (Untrusted) Core kernel (Trusted) 38

39 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

40 Rust Rule A memory location can have one read/write pointer or multiple read-only pointers mutable references and references in Rust parlance 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 40

41 Why 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; },... } 41

42 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 6lowpan timeout recv timer RF233 42

43 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

44 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 timeout timer timeout timer 6lowpan 6lowpan recv RF233 recv RF233 Safe Unsafe 44

45 System Call Insight grant grant Processes (Any language) heap stack data RAM heap stack data Process Accessible Memory text Flash text Kernel (Rust) SPI I2C UART Console GPIO Timer HAL Scheduler Config Capsules (Untrusted) Core kernel (Trusted) 45

46 System Call Insight Processes (Any language) Kernel (Rust) grant heap stack data text RAM Flash grant heap stack data text HAL Scheduler Config Process Accessible Memory Capsules (Untrusted) Core kernel (Trusted) Processes given block of memory Dynamically allocated when process loaded Kernel can allocate memory from process But references can t escape 46

47 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 references to a container Can pass a closure into the cell self.tx_client.get().map( c { c.send_done(buf.unwrap(), ReturnCode::SUCCESS); }); caller sam4l::spi::spi regs reading callback writing dma_read read_buffer dma_write write_buffer dma_length grant container function 47

48 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 self.apps.enter(appid, app, _ { app.read_buffer = Some(slice); app.read_idx = 0; 0 }).unwrap_or(-1) caller grant container function 48

49 Tock Status Support for three platforms imix: multicore development board signpost: extensible community sensing platform squall/nrf51: BLE/CortexM0 SoC Increasing community support launchxl platform EK-TM4C1294X (launchpad) nrf52 Other platforms: security USB devices, etc. 49

50 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

51 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

52 Thank you! Philip Levis Stanford Embedded Systems Mark Horowitz Stanford Hardware Zakir Durumeric Stanford Internet Security Dan Boneh Stanford Cryptography Dawson Engler Stanford Software Keith Winstein Stanford Networks Peter Bailis Stanford Databases David Mazières Stanford Security Björn Hartmann Berkeley Prototyping Raluca Ada Popa Berkeley Security Prabal Dutta Berkeley/Michigan Embedded Hardware David Culler Berkeley Low Power Systems Steve Eglash Stanford Executive Director Philip Levis Stanford Faculty Director 52

53 Questions 53