securecore : a multicore-based intrusion detection architecture for real-time embedded systems

SecureCore: A Multicore-based Intrusion Detection Architecture for Real-Time Embedded Systems

Man-Ki Yoon, Sibin Mohan, Jaesik Choi, Jung-Eun Kim, Lui Sha

Dept. of Computer Science, UIUCInformation Trust Institute, UIUC Lawrence Berkeley National Lab

Apr 9th, 2013

2

Rethinking Real-Time Embedded System Security


Increased Capability

More Networked

Open, Standard Platform

More Vulnerable to

Security Attacks

3SecureCore: A Multicore-based Intrusion Detection Architecture for Real-Time Embedded Systems

SecureCore Architecture

Intrusion Detection, not prevention•Most critical component: control application•System recovery upon detection

Behavior monitoring•Predictable timing behaviors of real-time apps•Profile using statistical learning

Multicore-based core-to-core monitoring•On-chip HW for processor state inspection•Hypervisor-based protection/isolation


4

Rest of the Talk• System and Application Model• Timing-based Intrusion Detection (Overview)• SecureCore

– Architecture Design– Timing-based Intrusion Detection (Detail)

• Implementation and Evaluation• Limitations and Future Work


5

• Multicore-based Real-Time Control System

System and Application Model


Physical plant

Time

Controller

Sensor data

Sensor data

Actuation cmd

Actuation cmd

Threat Model: Malicious code execution• Embedded in the control code• Activated after system initialization

• Irrelevant how it gained entry

SecureCore MonitoredCore


6

Timing-Based Intrusion Detection

• Idea: Deterministic timing of real-time applications – Any malicious activity consumes finite time to execute– Deviation from expected timing → Suspicious!


Block 1

Block 2

Block 3

Block 4 Block 5

Block 6

𝒆𝟏

𝒆𝟐

𝒆𝟑

𝒆𝟒 𝒆𝟓

𝒆𝟔

Malicious Code

𝑒3∗≠𝑒3

Observed Legitimate

7




Block 1

Block 2

Block 3

Block 4 Block 5

Block 6

𝑒1

𝑒2𝑒3

𝑒4 𝑒5

𝑒6

𝑒6∨ h𝑝𝑎𝑡 1=3𝑚𝑠𝑒6∨ h𝑝𝑎𝑡 2=7𝑚𝑠𝑒6∨ h𝑝𝑎𝑡 3=5𝑚𝑠

𝑒6∨ h𝑝𝑎𝑡 2 , 𝑖𝑛𝑝𝑢𝑡 𝑋=7𝑚𝑠𝑒6∨ h𝑝𝑎𝑡 2 , 𝑖𝑛𝑝𝑢𝑡𝑌=9𝑚𝑠

𝑒6∨ h𝑝𝑎𝑡 2 , 𝑖𝑛𝑝𝑢𝑡 𝑋=?𝑚𝑠

Execution time variations

Controlflow path Input values

System effects(e.g., shared

resource)

8




Block 1

Block 2

Block 3

Block 4 Block 5

Block 6

𝑒1

𝑒2𝑒3

𝑒4 𝑒5

𝑒6

𝑒6∨ h𝑝𝑎𝑡 1=3𝑚𝑠𝑒6∨ h𝑝𝑎𝑡 2=7𝑚𝑠𝑒6∨ h𝑝𝑎𝑡 3=5𝑚𝑠

𝑒6∨ h𝑝𝑎𝑡 2 , 𝑖𝑛𝑝𝑢𝑡 𝑋=3𝑚𝑠𝑒6∨ h𝑝𝑎𝑡 2 , 𝑖𝑛𝑝𝑢𝑡 𝑌=2𝑚𝑠

𝑒6∨ h𝑝𝑎𝑡 2 , 𝑖𝑛𝑝𝑢𝑡 𝑋=?𝑚𝑠

Execution time variations

Controlflow path Input values

System effects(e.g., shared

resource)• Profile probabilistic execution time model

• Estimate Prob(e*)• Capture even legitimate variations

Statistical learning-based profiling/detection

272000 274000 276000 278000 280000 2820000.00000.00020.00040.00060.00080.00100.00120.00140.00160.00180.0020

Execution Time

Prob

. Den

sity

9

Outline• System and Application Models• Timing-based Intrusion Detection (Overview)• SecureCore




10



Plant

ComplexController

SafetyCtrl.

DecisionModule

SensorData

ActuationCommandSimplex Architecture [Sha, 2001]

• For reliable & loss-less control

Monitored Core Secure Core

OS OS

Hype

rviso

r

Hypervisor • Memory space separation• Trust base

I/O Proxy• Manages I/O to/from the plant• Prevent I/O data obfuscation

I/OProxy

Inter-CoreCommunication

TimingTrace

Module

ScratchPad

Memory

SecureMonitor

Timing Trace Module (TTM)Read processor states when a trace instruction is executed

Scratch Pad Memory (SPM)• Stores a sequence of trace information• Only visible to the secure core

Secure Monitor• Verify the legitimacy of an execution• Use timing profile

11


• Block-level monitoring– Narrowing estimation domain

• Less variation, better accuracy

– Block boundary: check point• Detect unexpected flow deviations


Block 1

Block 2

Block 3

Block 4 Block 5

Block 6

12

How to Get Timing Profiles


Raw Traces Trace Tree ProfilesBlock

1

Block 2

Block 3

Block 4

Block 5

Block 6

Block 6

Block 6

Block 1

Block 2

Block 3

Block 4

Block 5

Block 6

Block 6

Block 6

2720002740002760002780002800002820000.00000.00020.00040.00060.00080.00100.00120.00140.00160.00180.0020 Statistical Learning

13

Timing Trace Module


rlwimi 0,0,0,0,1rlwimi 0,0,0,0,2rlwimi 0,0,0,0,3rlwimi 0,0,0,0,4

INST_REG_PIDINST_ENABLE_TRACEINST_DISABLE_TRACEINST_TRACE

foo() {

INST_TRACE; Do_something(); INST_TRACE; Do_something(); INST_TRACE;}

main() { INST_REG_PID; … INST_ENABLE_TRACE; … foo(); ... INST_DISABLE_TRACE;}

Trace Instructions

Timestamp i+2

PID BA AddrHead

Timestamp i Addr i

Timestamp i+1 Addr i+1

Addr i+2

...

...

AddrTail0x000

Timestamp j Addr j

Timestamp j+1 Addr j+10x010

0xFF0

4 Bytes

0x8a0

0x8b0

0x8c0

SPM Layout

- PID registration for preventing traces from being forged - BA: Base Address ( = PC of INST_REG_PID)- Read Timestamp and Program Counter from the processor registers- Addri = BA – PCi (i.e., relative address from BA)

14

Raw Traces


Block 1

Block 2

Block 3

Block 4 Block 5

Block 6

INST_TRACE

INST_TRACE

INST_TRACE

INST_TRACE

INST_TRACE INST_TRACE

INST_TRACE

Addr1

Addr2

Addr3

Addr4

Addr6Addr5

Addr7

(Addr1, t5)(Addr2, t6)(Addr4, t7)(Addr6, t8)(Addr7, t9)(Addr1, t10)(Addr2, t11)(Addr4, t12)(Addr5, t13)(Addr7, t14)

…

(Addr1, t1)

(Addr3, t3)(Addr7, t4)

(Addr2, t2)

15

Trace Tree


(Addr1, t5)(Addr2, t6)(Addr4, t7)(Addr6, t8)(Addr7, t9)(Addr1, t10)(Addr2, t11)(Addr4, t12)(Addr5, t13)(Addr7, t14)

…

(Addr1, t1)

(Addr3, t3)(Addr7, t4)

(Addr2, t2)Addr1

Addr3

Addr2

Addr7B

lock

1

Blo

ck 2

Blo

ck 6

Addr4

Addr5

Addr7

Blo

ck 6

Blo

ck 4

Addr2

Addr6

Addr7

Addr4

Blo

ck 6

Blo

ck 3

Blo

ck 5

t2-t1

t3- t2

t4- t3

t6-t5t11-t10

t7-t6t12-t11

t13-t12

t9-t8

t8-t7

t14-t13

…… …

…

… ……

Same execution block, but on

different paths.

Each has its own timing profile

From a trace tree, we can get• Execution time samples (each node)• Legitimate execution flows

16

Timing Profile• What is a good estimation of execution times?

– Min & max, mean, …• Not representative• Cannot capture variations well

– Probabilistic timing model• Estimate the likelihoods of execution times!

– Probability distribution• Parametric vs. Non-parametric distribution

– Unknown shape


17

(Fig

ure

is fr

om C

SCE

666

Patte

rn A

naly

sis b

y Ri

card

o Gu

tierr

ez-O

suna

at T

AMU

)

Example

Execution Time Profile Using Kernel Density Estimation (KDE)

• Non-parametric Probability Density Function Estimation


1

2

3

1. Given samples of execution times

2. Draw scaled distribution at each sample point

3. Sum them up

- Kernel & bandwidth affect shape and smoothness- Gaussian kernel

Estimated pdf

Kernel function

Bandwidth (Smoothing constant)

18

Intrusion Detection Using Timing Profiles


272000 274000 276000 278000 280000 2820000.0000

0.0002

0.0004

0.0006

0.0008

0.0010

0.0012

0.0014

0.0016

0.0018

0.0020

Execution Time

Prob

. Den

sity

PDF of the Execution Time of an example block

Highly likely

Multiple peaks: different inputs or system effects

How much deviation should we consider malicious?

Threshold test

Prob (𝑒¿¿∗)<𝜽 ¿Prob (𝑒¿¿∗)≥ 𝜽 ¿

Malicious

Legitimate

•E.g., or

•At least of measurements were close to

19

Summary of Timing-Based Intrusion Detection


ComplexController

SecureMonitor

Monitored Core Secure CoreTimingTrace

Module

ScratchPad

Memory

Addr1

Addr3

Addr2

Addr7

Blo

ck 1

Blo

ck 2

Blo

ck 6

Addr4

Addr5

Addr7

Blo

ck 6

Blo

ck 4

Addr2

Addr6

Addr7

Addr4

Blo

ck 6

Blo

ck 3

Blo

ck 5

[Profile]

Block 1

Block 2

Block 3

Block 4

Block 5

Block 6

[Run-time Execution]

(Addr1, ti)(Addr2, ti+1)(Addr4, ti+2)(Addr6, ti+3)(Addr7, ti+4)

Trace

Traverse andcheck

20

Outline• System and Application Models• Timing-based Intrusion Detection (Overview)• SecureCore




21

Implementation


CC SCDM

SM

Monitored Core Secure Core

IOP

LWE Linux 2.6.34

TTM

SPM

Hype

rviso

rInverted

Pendulum (IP)Dynamics

Simics (P4080)Host PC

Serial (tty) Pseudo Terminal (pts)Byte channel

Freescale P4080 on Simics• Only two cores (Core 0 and 1)• Cache (L1 and L2) and bus models for system effects• ISA modification for trace instruction

Inverted Pendulum Control • Controller and dynamics (cart position, rod’s angle)• Generated from Simulink IP model

22

Application Model• IP Control + FFT (EEMBC)


FFT Init

FFTPhase #1

FFTPhase #2

FFTPhase #3

IP Control

PathID = 1, 2

PathID = 0

1 run if PathID = 0, 1

2 runs if PathID = 2

0 + 1 meter

Malicious code• Injected at the end of FFT Phase #3• Simple loop (some array copy)

• 440, 720, 1000 cycles for 1,3,5 loops• (FFT Phase#3: ~260,000 cycles)

• Activated when the cart passes +0.7 m• Execute randomly thereafter

• Loop execution• Sends old actuation cmd

Timing Profile• ~10,000 runs (no malicious code activation)• ‘ksdensity’ (Matlab) for Gaussian KDE

• Total exec time: 850,000 ~ 1,200,000 cycles (~1ms)• Control period: 10 ms

23

Early Detection


0 5 10 15 20 25 300

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

Time (sec)

Car

t pos

ition

(met

er)

No attack

(1%)Loop count: 3 ( ~ 720 cycles)

0 5 10 15 20 25 300

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

Time (sec)

Car

t pos

ition

(met

er)

No attackNo protection

Attack activated

0 5 10 15 20 25 300

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

Time (sec)

Car

t pos

ition

(met

er)


Simplex only

Attack activated

0 5 10 15 20 25 300

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

Time (sec)

Car

t pos

ition

(met

er)


Simplex only

Our methodAttack activated

24

Intrusion Detection Accuracy


• Criteria: False prediction rates– False positive: predict “malicious” when not– False negative: fail to detect a real attack

PredictedReal

1/1024 (0.10%)

7/1015 (0.69%)

1 loop 3 loops 5 loops

827/1022 (81%) 574/1046 (55%) 130/1098 (12%)

578/1050 (55%) 117/1011 (12%) 0/1024 (0%)

False positive rates False negative rates

Trade off: Low ? High ?

Detect well More false alarms

Miss often Fewer false alarms272000 274000 276000 278000 280000 282000

Execution Time

Prob

abili

ty

Low

High

25

Limitations and Future Work• Limitations

– Low detection accuracy for short malicious code→ More deterministic execution

– Still high false positive→ Long-term monitoring

• Other future work– Monitoring multiple applications on multiple cores– Monitoring of other behavioral aspects (e.g., Memory, I/O)– Multi-dimensional monitoring


26

Thank you


securecore : a multicore-based intrusion detection architecture for real-time embedded systems

Documents

realtime control systemsystem

expected timing suspicious

malicious activity

future work securecore

finite time

control codeactivated

application modelsecurecore

lui sha