li ghtweight s warm a ttestation: a alet of wto...

LIghtweight Swarm Attestation:a Tale of Two LISA-s

Xavier Carpent, Karim ElDefrawy, Norrathep Rattanavipanon,Gene Tsudik

UC Irvine

April 3, 2017

http://sprout.ics.uci.edu

1 / 22

IoT/CPS

This is why we can't have nice things

2 / 22

�Swarms� of IoT

Drones: Video surveillance, environment monitoring

Robot swarms: Prospecting, rescue, etc.

Smart factories and buildings (home/o�ce): Collabo-rating CPS

Transportation: Automotive, marine, avionic systems

3 / 22

Remote Attestation

Remote Attestation (RA)

I Veri�cation of internal state of a prover by a veri�er

I Challenge-response protocol

I Prover is untrusted

I Veri�er is trusted (i.e. not infected)

Vrf Dev

chal

resp

4 / 22

Software, Hardware, and Hybrid Solutions

Software Attestation

I Strong assumptions on adversary behaviour

I Time-sensitive (no real �remote� attestation)

I Typically for legacy devices

Hardware Attestation

I Secure hardware (e.g. TPM)

I Relatively high cost/size/energy

I Impractical in medium/low-end IoT devices

Hybrid Attestation

I Minimal hardware support for secure RA

I Provides non-interruptibility/memory isolation/protectedaccess

5 / 22

SMART

Dev Software

SMART Vars

K

SMART AttCode

rwr

RAM ROM

Features

I ROM for AttCode

I MCU access controls

I Rules preprogrammed statically

SMART for RA

I AttCode atomic and complete

I Protected access to K

I Small impact on architecture

Secure & Minimal Architecture for Remote Trust (NDSS '12)A Mminimalist Approach to Remote Attestation (DATE '14)

6 / 22

SMART as a black box

I MAC (e.g. keyed hash) of (a part of) Dev 's memoryI sign could also be used, with typical PKC/SKC pros/consI Physical attackers not consideredI Using key K , protected from non-physical attacksI Non-interruptible

attest

Memory h MAC

K

�SMART+� = SMART with Vrf authentication (DoS mitigation)Remote Attestation for Low-end Embedded Devices:

the Prover's Perspective (DAC '16)

7 / 22

SMART as a black box

I MAC (e.g. keyed hash) of (a part of) Dev 's memoryI sign could also be used, with typical PKC/SKC pros/consI Physical attackers not consideredI Using key K , protected from non-physical attacksI Non-interruptible

attest

Memory h MAC

K

�SMART+� = SMART with Vrf authentication (DoS mitigation)Remote Attestation for Low-end Embedded Devices:

the Prover's Perspective (DAC '16)7 / 22

Swarm Attestation

Vrf D1

D2

D3

D4

D5

D6

D7

D8D9

8 / 22

Swarm Attestation

Vrf D1

D2

D3

D4

D5

D6

D7

D8D9

D1

D2

D3

D4

D5

D6

D7

D8D9

8 / 22

Swarm Attestation

D1

D2

D3

D4

D5

D6

D7

D8D9

Vrfattest

attest

attest

attest

8 / 22

Swarm Attestation

D1

D2

D3

D4

D5

D6

D7

D8D9

Vrfattest

attest

attest

attest

Vrfattes

t

attest

8 / 22

Swarm Attestation

D1

D2

D3

D4

D5

D6

D7

D8D9

Vrfattest

attest

attest

attest

Vrfattes

t

attest

Vrfattest

attest attest

8 / 22

Swarm Attestation

D1

D2

D3

D4

D5

D6

D7

D8D9

8 / 22

Swarm Attestation

D1

D2

D3

D4

D5

D6

D7

D8D9

Vrf

8 / 22

SEDA

Scalable Embedded Device Attestation (CCS '15)

Features

I First attempt at swarm attestation

I Performs signi�cantly better than individual attestations

Limitations

I Static and pre-determined topology

I Under-speci�ed (architectural impact, timing, burden/state indevices)

I Unnecessary features (e.g. PKC)

9 / 22

Contributions

Quality of Swarm Attestation (QoSA)

I Binary

I Intermediate (count)

I List (or complement)

I Full (topology)

Two Protocols

I LISAα � asynchronous protocol

I LISAs � synchronous protocol

I Simulation and comparison

Practical Considerations

I Initiator selection

I Timeouts (important because �not responding� = �infected�)

I State

10 / 22

Lightweight Swarm Attestation � Asynchronous Version

LISAα

Rationale

I Intuitive/simple

I Minimal changes over single-prover attestation

I Quasi-stateless

I Focused on fastest overall attestation

11 / 22

LISAα � Asynchronous Version

Vrf

D1

D2 D3

D4 D5

Waitstart

VerifyRequest

VerifySession

Broadcast+ Attest

Forward

req

rep

7

3

7

3

12 / 22

Lightweight Swarm Attestation � Synchronous Version

LISAs

Rationale

I Reduces communication complexity

I At the cost of longer overall attestation

I (but amount of work remains the same)

13 / 22

LISAs � Synchronous Version

Vrf

D1

D2 D3

D4 D5

Wait

start

Broadcast+ Answer

AcceptChild

VerifyRequest

Verify+ Ack

VerifySession

Attest+ Answer

Aggregate

req

rep

ack

timeout

7

3

7

3

73

done

14 / 22

Simulation

I CORE emulator

I Script to generate networks randomly (up to 40 nodes)

15 / 22

Cryptographic Considerations � Raspberry Pi-2 @ 900MHz

16 / 22

Comparison � Average Total Attestation Time

17 / 22

Comparison � Average CPU Time per Device

18 / 22

Comparison � Average Bytes Transmitted per Device

19 / 22

Comparison and Conclusion

QoSA

DoS Resilience

footprint

complexity

bandwith

adversary resilience

bin

ctrlist

topologyremote

local

physicalLISAα

LISAs

20 / 22

Comparison and Conclusion

Contributions

I De�nition and diversi�cation of QoSA

I Protocols that are �closer to practice�

I Simulation shows negligible overhead (w.r.t. crypto)

LISAα

I Less overal attestation time

LISAs

I Less overal bandwidth

I Fewer packets

21 / 22

Future Work

Formal Proof

Trial Deployment

Heterogeneous Devices

I Devices with various CPU/networking capabilities?

I Devices with di�erent security architectures(software/hybrid/hardware)?

Mobility

I How to handle swarms with strong mobility (intra-attestation)?

22 / 22

li ghtweight s warm a ttestation: a alet of wto...

Documents