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 1
Internet-of-things (IoT) 2
3
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 4
Verifier Prover (1) Challenge (2) Authenticate challenge and measure memory (3) Response (4) Verify response 5
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 6
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 7
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 8
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) 9
RA vs Safety-Critical Operations SMART-BASED MSP430 @ 8MHZ HYDRA-BASED ODROID @ 2GHZ 4.5 seconds to measure 48KB of flash 7 seconds to measure 1GB of RAM Atomicity negatively impacts device’s availability to critical app. 10
Why Atomicity is Needed? • Remove atomicity -> vulnerable to the following attack: Memory Blocks 1 2 3 4 5 6 11
Why Atomicity is Needed? • Remove atomicity -> vulnerable to the following attack: Memory Blocks 1 1 2 2 3 3 4 4 5 5 6 6 11
Why Atomicity is Needed? • Remove atomicity -> vulnerable to the following attack: Memory Blocks 1 2 3 4 5 6 11
Why Atomicity is Needed? • Remove atomicity -> vulnerable to the following attack: Measurement result Memory Blocks 1 2 3 4 5 6 reflects malware-free state! Roving Malware Conflict • Atomicity and real-time/safety-critical needs. • Also, minimize hardware cost 11
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 12
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • Idea: measure memory in random and secret order • Allow block-level interrupts 13
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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} 13
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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} 13
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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} 13
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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} 13
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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} 13
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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} 13
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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 } 13
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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 14
Roving malware’s knowledge? Knowledge of Type How to obtain 1 2 3 4 5 6 Permutation = {3, 2, 5, 6, 1, 4} 15
Roving malware’s knowledge? Knowledge of Type How to obtain Future volume Time when measurement KFV 1 2 3 4 5 6 starts Permutation = {3, 2, 5, 6, 1, 4} 15
Roving malware’s knowledge? Knowledge of Type How to obtain Future volume Time when measurement KFV 1 2 3 4 5 6 starts Permutation = {3, 2, 5, 6, 1, 4} 15
Roving malware’s knowledge? Knowledge of Type How to obtain Future volume Time when measurement KFV 1 2 3 4 5 6 starts Future HW/SW side-channel Permutation = {3, 2, 5, 6, 1, 4} KFC coverage 15
Roving malware’s knowledge? Knowledge of Type How to obtain Future volume Time when measurement KFV 1 2 3 4 5 6 starts Future HW/SW side-channel Permutation = {3, 2, 5, 6, 1, 4} KFC coverage 15
Roving malware’s knowledge? Knowledge of Type How to obtain Future volume Time when measurement KFV 1 2 3 4 5 6 starts Future HW/SW side-channel Permutation = {3, 2, 5, 6, 1, 4} KFC coverage Future order Leakage of permutation KFO 15
Roving malware’s knowledge? Knowledge of Type How to obtain Future volume Time when measurement KFV 1 2 3 4 5 6 starts Future HW/SW side-channel Permutation = {3, 2, 5, 6, 1, 4} KFC coverage Future order Leakage of permutation KFO 15
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 16
Probability of Malware Evasion 16
SMARM Implementation 17
SMARM Implementation (without secure storage) 18
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 19
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 20
Q/A 21
40% 10,636% 0.8% 41% n = 32 n = 2048 t = 0.4s t = 0.006s 39
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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} 40
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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! 41
Our Solution • SMARM : S huffled M easurement A gainst R oving M alware • 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 42
Recommend
More recommend