IoT: Security for 20 Years

IoT Rereat, June 28, 2016

Privacy, Discovery, and Authentication for the

Internet of Things

David Wu, Ankur Taly,

Asim Shankar, Dan Boneh

To appear in ESORICS 2016

Private discoverySome devices: visible to visitorsSome only visible to staffSome only visible to residents

Discovery today:MulticastDNS,AppleAirDrop,BLE

Littleusercontrol(andproblemswithAirDrop)

Nanny cam

Alarm system

Our workPrivate service discovery: • devices are only discoverable by authorized entities• moreover, if authorized, establish auth. shared key

The problem:• Device identifies itself only after it learns that client is

authorized to see the device

• Client (phone) should not identify itself to arbitrary devices

Who goes first?

SolutionFamilyofprotocolsprovidingprivatediscovery

• Example:SIGMA-basedprotocolusingsecrethandshakes

• ReasonableperformanceonIoT platforms:

Quantum Resistance in TLSfrom Learning-With-Errors

V. Nikolaenko, I. Mironov, A. Raghunathan

Quantum computers: opportunities and challenges

Many algorithmic speed-ups: (e.g. in computational chemistry)• Finding a satisfying assignment:

P: K ⟶ {0,1} is zero almost everywhereexample: P(k) = 1 ⟺ AES(k, input) = output

Grover: can find k s.t. P(k)=1 in time O(|K|1/2)

⇒ break AES128 in time 264

⇒ find collisions on SHA256 in time 286

• Period finding: f: ℤ2 ⟶ X s.t. ∀z: f(z + d) = f(z). Find d.Shor: can find d in time O(log d)

⇒ compute Dlog in group of order N in time O(log N)

Is it real?Considerable recent progress:• Google (John Martinis, UCSB)• IBM• and startups

Current record: small number of physical qbits (noisy)• Good for shallow computations• ×1000 for error correction• Shor: ≈10,000 clean qbits, circuit depth ≈100,000.

What do to?The only difficult question:• Quantum resistant key-exchange

Goal: fast key-exchange based on a computational problem that is difficult for a quantum computer

Candidate: Learning With Errors (LWE) [Regev’05]

Impact on TLS:• Traffic: ≈ 11KB bytes in each direction (32 bytes with ECDH)

• CPU time: not the bottleneck

TOCK:A Safe Multi-tasking Operating

System for Microcontrollers

Amit Levy Branden Ghena Bradford Campbell

Pat Pannuto Prabal Dutta Philip Levis

Problem: Processes are too resource heavy

Processes are the primary isolation mechanism in OSs • Encapsulates isolation memory + execution state• Reserved memory for each process• Message passing for communication

A poor match for securing resource constrained devices: ⇒ Limited memory so can only fit a few processes⇒ Hard to meet timing constraints with context switches

A solution: TockRust type system for many kernel components • called Capsules

Hardware protection for a few processes

Resolves isolation granularity vs. resource consumption: • Single-threaded

asynchronous event system

• Type encapsulation for isolation

Tock system architecture

Sensing and monitoring app

Results: Capsules are much more efficient

Our port for Firestorm platform:• >100 capsule instances in 7Kib memory • 7 processes with 8KiB memory each

Capsules have much lower communication overhead

save sys-call cost

Embark: Securely Outsourcing Middleboxes to the Cloud

Chang Lan, Justine Sherry,

Raluca Ada Popa, Sylvia Ratnasamy, Zhi Liu

UC Berkeley

The Problem

High-level▶ Outsource middleboxes to the cloud without leaking traffic content?

Low level▶ Can we design crypto primitives for the two basic operations, i.e.

signature matching and prefix matching?

SolutionCrypto Primitives

▶ Signature Matching: KeywordMatch from BlindBox [SIGCOMM 2015]

▶ Prefix Matching: PrefixMatch from Embark [NSDI 2016]

PrefixMatch in detail▶ Property: answer if a value V matches a range Ri from [R1, R2, ...]

▶ Security Guarantee:• Do not reveal the value of V and Ri• If both V1 and V2 match Ri, do not reveal the ordering between

V1 and V2

PrefixMatch vs. OPEOrder-preserving Encryption

▶ Preserve the ordering of values after encryption▶ Applicable to this context

PrefixMatch is better:▶ More secure (No relative ordering)▶ Faster (~10000x)

Operation BCLO mOPE PrefixMatch

Encrypt,10krules 9333us 6640us 0.53us

Encrypt,100krules

9333us 8300us 0.77us

Decrypt 169us 0.128us 0.128us

CESEL: Flexible Hardware for Accelerating Cryptography

Kevin KininghamDan Boneh, Phil Levis, Mark Horowitz

Stanford University

Flexible Hardware: motivation“20 year” security– Algorithms change with mathematical advances– Security requirements change over time

Forward and backward compatibility– Don’t want to replace obsolete hardware– May be embedded in physical object– Potentially millions of devices to replace

Regional variation in crypto systems– Want to sell same device to Russia, China, USA, etc

What is CESEL?

• Hardware architecture for flexible cryptography

FastHashFunction ECCCoprocessor

R-LWECoprocessor HWRNGandHWCounter

Micro-controllerwithextendedinstructionsS-Box

PolynomialMultiplication

VectorArithmetic

MemoryBus

Current Work• Design effort focused on asymmetric processor

• Our design gives latency ~ vs. ~ on cpu

• Current implementation work– Verilog implementation– Running experiments and fine tunning

• Beyond: Whole system view– How does algorithm perform with bus overhead?

THE END