Remote Attestation of IoT Devices via SMARM: Shuffled Measurements - - PowerPoint PPT Presentation

Remote Attestation of IoT Devices via SMARM: Shuffled Measurements Against Roving Malware

Xavier Carpent, Norrathep (Oak) Rattanavipanon, Gene Tsudik nrattana@uci.edu SPROUT Lab: sprout.ics.uci.edu University of California, Irvine

Internet-of-things (IoT)

Remote Attestation (RA)

• An approach for detecting malware on devices
• Two-party interaction between:
• Verifier: trusted entity
• Prover: potentially infected and remote IoT device
• Goal: to verify internal state of prover

(1) Challenge (3) Response (2) Authenticate challenge and measure memory (4) Verify response

Verifier Prover

Adversarial Model [DAC’15]

• Remote adversary
• Exploits vulnerabilities to inject malware
• Local adversary
• Manipulates communication channel
• Physical adversary
• Non-Invasive: mounts hardware side-channel attacks
• Invasive: physically changes hardware

Adversarial Model [DAC’15]

• Remote adversary
• Exploits vulnerabilities to inject malware
• Local adversary
• Manipulates communication channel
• Physical adversary
• Non-Invasive: mounts hardware side-channel attacks
• Invasive: physically changes hardware

RA Techniques

• Hardware-based RA
• Dedicated hardware support (e.g. TPM or Intel-SGX)
• Overkill for lower-end IoT devices
• Software-based RA
• Relies on precise timing measurement
• Unrealistic assumptions for IoT except peripheral/legacy

devices

• Hybrid RA
• SW/HW co-design
• Minimal hardware impact
• Good fit for IoT devices

Examples of hybrid RA

• SMART [NDSS’08]: RA for low-end micro-controllers
• Some of key properties:
• Secure storage (for key, code and monotonic counter)
• Atomic execution: measurement process runs without interruption
• HYDRA [WiSec’17]
• Emulation of SMART on devices capable of running micro-kernels
• Based on formally verified seL4 micro-kernel
• Hardware-assisted secure boot (only hardware feature)

RA vs Safety-Critical Operations

SMART-BASED MSP430 @ 8MHZ 4.5 seconds to measure 48KB of flash HYDRA-BASED ODROID @ 2GHZ 7 seconds to measure 1GB of RAM

Atomicity negatively impacts device’s availability to critical app.

Why Atomicity is Needed?

• Remove atomicity -> vulnerable to the following attack:

1 2 3 4 5 6

Memory Blocks

Why Atomicity is Needed?

• Remove atomicity -> vulnerable to the following attack:

1 2 3 4 5 6

Memory Blocks

1 2 3 4 5 6

Why Atomicity is Needed?

• Remove atomicity -> vulnerable to the following attack:

1 2 3 4 5 6

Memory Blocks

Why Atomicity is Needed?

• Remove atomicity -> vulnerable to the following attack:

1 2 3 4 5 6

Memory Blocks

Roving Malware

Conflict

• Atomicity and real-time/safety-critical needs.
• Also, minimize hardware cost

Measurement result reflects malware-free state!

Target Devices for Our Solution

• Simple IoT devices
• Single-core processor
• No memory protection mechanism
• Run two tasks
• Measurement task
• Safety-critical/real-time task
• Hybrid RA architecture

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts
• Similar to some of SW-based RA approaches
• Memory is measured in random but not secret!
• Security = precise timing of measurement
• Security of our solution = that of hybrid RA: attestation key +

random/secret permutation

Roving malware’s knowledge?

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Type Knowledge of How to obtain

Roving malware’s knowledge?

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Type Knowledge of How to obtain KFV Future volume Time when measurement starts

Roving malware’s knowledge?

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Type Knowledge of How to obtain KFV Future volume Time when measurement starts

Roving malware’s knowledge?

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Type Knowledge of How to obtain KFV Future volume Time when measurement starts KFC Future coverage HW/SW side-channel

Roving malware’s knowledge?

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Type Knowledge of How to obtain KFV Future volume Time when measurement starts KFC Future coverage HW/SW side-channel

Roving malware’s knowledge?

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Type Knowledge of How to obtain KFV Future volume Time when measurement starts KFC Future coverage HW/SW side-channel KFO Future order Leakage of permutation

Roving malware’s knowledge?

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Type Knowledge of How to obtain KFV Future volume Time when measurement starts KFC Future coverage HW/SW side-channel KFO Future order Leakage of permutation

Best Strategy of KFV Roving malware

❖ Assume malware is contained in one memory block ❖ Knows how many blocks have/have not been measured ❖ Can interrupt right after measurement of each block

Best strategy: interrupt and relocate

Probability of Malware Evasion

SMARM Implementation

SMARM Implementation (without secure storage)

Related Work

❖ ERASMUS [DATE’17], SeED [WiSec’17]

❖ Self-measurements ❖ Schedule measurement to whenever Prover is available ❖ Require secure clock

❖ Temporal Consistency [AsiaCCS’18]

❖ Allow interrupts by locking memory ❖ Require hardware support for locking memory

❖ Reconciling RA and Safety-Critical Operation on IoT Devices [DAC’18]

❖ Survey techniques that aim to resolve this conflict

Conclusion

• Investigate conflict arisen from reconciling real-time needs and

security properties in RA

• Enforcing atomicity → harmful to safety-critical applications
• Simply removing atomicity → vulnerable to attacks from roving malware
• Our solution: SMARM
• Goal: relax atomicity + (probabilistically) detect roving malware
• Measure memory in random and secret order
• Require multiple measurements to ensure high detection rate
• + Allow interrupts in measurement process
• + No hardware change/optionally secure storage

Q/A

41% 10,636% n = 2048 t = 0.006s

n = 32 t = 0.4s 0.8% 40%

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Get Caught!

Our Solution

• SMARM: Shuffled Measurement Against Roving Malware
• Idea: measure memory in random and secret order
• Allow block-level interrupts

1 2 3 4 5 6

Permutation = {3, 2, 5, 6, 1, 4}

Successfully Escape