On Securing Networked Real-Time Embedded Systems

Kang G. ShinKang G. Shin

The University of MichiganThe University of Michigan

`Real-Time & Embedded’ Everywhere!

Recent past DARPA and NSF Programs: DARPA: MoBIES, NEST, SEC, SenseIT, PECES, PAC/C, QUORUM,

Embeddable Systems, … NSF: Hybrid Embedded Systems,….

Embedded Systems/Devices Handheld devices (telcomm, PDAs, palmtops), smart sensors

and actuators (military and industry) Games and entertainment Smart cars, homes/buildings Embedded medical devices Ad hoc networks of sensors and actuators

“Bet is dot-net”

Smart appliances and consumer electronics everywhere at affordable prices!

HW and SW that let consumers and businesses exchange information via PCs Wireless phones Digital TVs

But these must be connected and integrated Analogous to “embrace and extend the Internet.”

Two Main Components

Consumers own/operate “end-” systems/devices which are seamlessly connected to the net.

End-systems and network have been, and will continue to be, developed independently

But consumers/apps want diverse QoS, irrespective of their type and location Need QoS support for both end-systems and network, and their

integration for e2e QoS QoS=> timeliness, dependability, security,…, which are not

independent.

Type of End-Systems/Devices

Gizmos and appliances: cell phones, palm PCs, consumer electronics, networked home appliances,….

Smart sensors and actuators At present largely best-effort but growing needs to support various types of QoS for voice/video over IP/WLANs, distance learning, net meetings, remote medical services, multi-party games, entertainment,…

Cost is a Major Issue!

Small-memory embedded systems used everywhere: automobiles factory automation and avionics home appliances

Massive volumes (10K-10M units) Saving even a few dollars per unit is important:

cheap, low-end and low-power processors max. 32-64 KB SRAM, often on-chip low-cost networks, e.g., Bluetooth, 802.11, CAN

Energy Is Also a Critical Resource!

Mobile, handheld devices Satellite, space and military

systems with limited power budgets Physical and thermal limitations on

systems Approaches:

Hardware: Limit parallelism and speculative

execution Improve circuit technology

Software: Perform fewer computations Improve algorithms and mechanisms,

e.g., DVS

OS for Small Embedded Systems

Code size ~ a few 10 kB, and small RAM ~ a few kB Must provide all basic OS services: IPC, task

synchronization, scheduling, I/O All aspects must be re-engineered to suit small-memory

embedded systems: API IPC, synchronization, and other OS mechanisms Task scheduling Networking Energy-efficiency

E.g., OSEKWorks, Lynx OS, and EMERALDS are typical examples=>Separation/partitioning kernel

Separation Kernel

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

Securing OS

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

QoS Assurance We know how to guarantee timeliness and

achieve a certain level of fault-tolerance on end- systems and networks in isolation

But their integration is still hard Adding fault-tolerance and security makes it

harder, especially in view of heterogeneity of devices, protocols, envrionments, and apps

One-fits-all solution is unacceptable and strong inter-dependencies exist among diff QoS dimensions=>need to make tradeoffs

SecureEmbedded Systems Unlike the desktop-software-security policy of

patch-after-failure, embedded products must continue operation in spite of security threats=>self-securing and organizing

Heterogeneity of embedded-system architectures provides multiple attack opportunities and prevents the development of an industry-wide security protection scheme.

Specialized, embedded, secure storage silicon and coprocessors offload security authentication and encryption tasks to dedicated hardware

What I’d like to sketch next Protection of embedded app SW and data

under untrusted OS Mobileworms Security of sensor networks

Imagine PDAs and smart cell phones will contain

important privacy info on your credit cards, bank accounts, SSN, passport and driver’s license #, personal contacts,…

Smart devices (e.g., cell phones) run games, movies, music,…

Digital pirates crack OS of the embedded device and have the willy OS collect personal info & copy the copy-righted contents

OS, Untrusted

OS distrusts applications. So do applications OS’s omnipotence/omniscience makes it hard to protect

privacy and copyrights of digital products Need a sound security model of untrusted OSes

In what sense, can applications not trust the OS?

OSHW

AppApp

App

vs.

HW

OS

App App App

Hierarchical (e.g., TCPA)

Free for all

Trust relationships

Threat Model: “Software Privacy”

Meaning of “untrusted” OS OS’s quality of service, observation and tampering

Privacy: a process can conceal code/data from others, including malfunctioning/willy OS

OS is malfunctioning OS tries to be unethical

Faulty OSFaulty OS

App1App1

App2App2 App3App3

App4App4

code/data encrypted

Information leakage

Poor quality of system service

Wily OSWily OS

App1App1

App2App2 App3App3

App4App4

code/data encrypted

Observation,

tampering

Application abusing

How to Achieve Privacy & App SW Protection from Untrusted OS?

Use a secure processor where memory content is encrypted, but existing secure processors are problematic Complex, restrictive, and incomplete APIs

These problems are due to Poor abstraction of OS Lack of analysis on a threat model

Need a sound model and a definite solution Threat model as “software privacy” Solution should be complete

Problems with Existing SPs What’s wrong with the conventional secure processor?

Lack of ‘simplicity’ and ‘completeness’, e.g., no secure sharing Poor interface makes SW/HW implementation difficult Irrelevance b/w hardware-copy/tamper-proof circuit and OS

E.g., problems of XOM [Lie, SOSP ‘03] architecture: Complex interface

XOM architecture requires 14 instructions Original XOM had 8, but OS development required more

Incompleteness – no secure sharing Sharing memory between processes is essential in OS construction

Shared memory, shared library When process forks, syscall and RPC argument passing

Unclear protection model Physical or logical? Hardware or software?

A Typical Secure Processor

Cryptographic hardware + MMU = secure processor Content of the main memory is encrypted Typically, per-process encryption A context switch requires special care

Encryption Hardware

Encryption Hardware

PID

L2

Cache

CPU

Key File

Register File

Main Memory

Physical

security

perimeter

Software Distribution Model

A customer who purchases software supplies Kp+ {Ks}Kp+{software image}Ks is what he gets Processor decrypts Ks. (The owner doesn’t know Kp-)

Software master copySoftware

master copy

Encrypted softwareEncrypted software

Symmetric key KsSymmetric key KsPublic key Kp+Public key Kp+

{Ks}Kp+{Ks}Kp+

Content delivery

Key delivery

Distributor’s randomly chosen

key

Encrypt using Ks

Customer side

Public key encrypt using purchaser’s

Kp+

Software distributor side

Encrypted softwareEncrypted software

Private key Kp-Private key Kp-

A Possible Solution

MapUnmap

GrantRevoke

AllocFree

µ

process-key

key file

σ

key-page

Machine stateInstructions

: Privileged instructions and operating system data structure: Secured data structure (protected by hardware)

Proximity Scanning

Use short-range RF such as Bluetooth to discover targets in range Range of bluetooth: 100m for Class-1 and 10m for Class-2 devices Recent incident of Cabir in Helsinki Olympic sports stadium Range of proximity scanning can be large (e.g., stadium, airport,

train/bus station, shopping mall, hospital, coffee shop)

Bluetooth Vulnerabilities Bluejacking: Anonymous transmission of data to a nearby device Bluesnarfing: Access to restricted data on a nearby device Bluebugging: Modification of data, serial (AT) access to launch

application on a nearby device

Here Come Mobile Worms!

Passive Worms

Set up a rogue WLAN AP for users (“free wireless”) Install Trojans and worms on vulnerable mobile devices

Mobility-Induced Propagation

Infected cell phone or mobile device uses proximity scanning while moving across cells or WiFI hotspots

Rate of propagation depends on proximity scanning range, mobility pattern of infected device, # of devices in cells:

Each infected device moves around and infects others (“cascade”) Only the original device moves across the network (“initial”)

Here Come Mobile Worms!, cont’d

Crossover Worms Are Already Here!

Propagate from wired to wireless or vice-versa

Wired-to-Wireless: first-generation attacks such as Timofonica, Minuka, Hacktool (launches SMS DoS on targeted phones)

Wireless-to-Wired: An attacker uses a mobile device to upload a regular scanning worm onto a wired host: Cardtrap (installs 3 “regular” worms on a device’s memory card)

=> Hard to trace back the original attacker

Here Come Mobile Worms!, cont’d

Propagation Factors for Mobile Worms/Viruses:

Connectivity (diverse radio interfaces, e.g., Bluetooth, 802.11b/WiFi, GSM, GPRS, 3G)

OS Vulnerabilities (Symbian, Palm, WinCE)

Windows/Unix (wired to wireless propagation)

Density of mobiles in a given network or in range (Stadium/Airport/Univ)

Target Discovery (SMS/MMS Buddy Lists, Bluetooth neighbor, etc.)

Mobility Patterns

Modeling and Containment Challenges

Each node is programmed as an individual agent with device attributes and service models

Nodes: Fixed/Wired: hosts, routers, access points, base stations Mobile: handsets, cell phones, laptops Special: Application Servers, verification and RL servers

Flexible service composition: SMS, Bluetooth, P2P, IM, Email, etc.

Wired Segment: Allows service-level mitigation

Mobility Models: Random Waypoint, Gauss-Markov

Agent-based Malware Modeling (AMM): An Approach

Challenges in Sensor Networks

Harsh, hostile, unattended deployment

Battery-powered, non-rechargeable

A large number of nodes

Self-organizing/healing

Need High-Level SecurityNeed High-Level Security

with Limited Energy Budgetwith Limited Energy Budget

=>LiSP =>LiSP

1/32

Common Objectives

Flexible

Lightweight

To prolong network lifetime

Symmetric-key ciphers, crypto hash functions

Attack-Tolerant

Gracefully tolerate attacks

Self-healing – detect & identify attackers

Cooperative

Collaboration & Cooperation among sensors/protocols

Security & energy tradeoffs

To large network size

ScalableCompatible

Existing security mechanisms

Energy-awareEnergy-awareSecuritySecurity

2/32

Taxonomy of AttacksOutsider / Non-cryptographic Insider / Cryptographic

Data Attacks• Traffic replay, modification & injection

• Eavesdropping, spoofing

Service Disruption Attacks• Routing

• Localization• Clock Synchronization

Resource Consumption Attacks

Denial-of-Service Attacks

Ra

dio

(Ja

mm

ing

) A

ttack

s

Wo

rmh

ole

Atta

cks

Ph

ysic

al A

ttack

s•

Cap

ture

vic

tims

•R

ever

se-e

ngin

eer

& r

epro

gram

pro

gram

s•

Re-

depl

oy c

ompr

omis

ed s

enso

rs

Syb

il A

ttack

s•

Mul

tiple

fict

itiou

s ID

s (lo

catio

ns)

3/32

Attack-Prevention ApproachTHREATTHREAT DEFENSEDEFENSE PROBLEMPROBLEM SOLUTIONSOLUTION

Key Sharing

Pre-deployment of keys

• Globally• Group-based• Pairwise• Combined

Group-basedKey Management

DistributedKey Sharing

• Re-keying ?

• Processing & communication overheads ?

• Sensor compromises ?

SoftTamper-Proofing

via

Program-IntegrityVerification

Protection of

program itself

Defenseless

once broken

TamperResistance

• Obfuscation• Result checking• Self decryption• Self checking

S/W

H/W

Attack on TrafficAttack on Traffic

• Eavesdropping

• Traffic replay,modification, injection

• Service disruption,DoS, Sybil, …

Attack on ProgramAttack on Program

The adversary can• capture• reverse-engineer• re-program• Clone sensor

device(s)

4/32

Attack-Tolerance ApproachO

BJE

CT

IVE

SO

BJE

CT

IVE

S

•G

race

fully

tol

erat

e at

tack

s

•D

etec

t, id

entif

y &

rem

ove

sour

ces

of a

ttac

ks•

Gra

cefu

lly t

oler

ate

atta

cks

•D

etec

t, id

entif

y &

rem

ove

sour

ces

of a

ttac

ksHOW ?HOW ?

Use

Distributed

Key

Sharing

Use

Distributed

Key

Sharing

Exploit

Spatio-Temporal

Correlation

Exploit

Spatio-Temporal

Correlation

SERVICESERVICE

RoutingRouting

LocalizationLocalization

Clock

Synchronization

Clock

Synchronization

SOLUTIONSOLUTION

SecureGeographicForwardingProtocol

SecureGeographicForwardingProtocol

Temporal-KeyEstablishmentProtocol

Temporal-KeyEstablishmentProtocol

Verification forIterativeLocalization

Verification forIterativeLocalization

Attack-TolerantClock SynchProtocol

Attack-TolerantClock SynchProtocol

5/32

Security & Energy Tradeoffs

LiSP Architecture

Key

Management

& Sharing

Key

Management

& Sharing

IntrusionDetectionIntrusionDetection

Program

Integrity

Verification

Program

Integrity

Verification

Attack-Tolerant Core ServicesAttack-Tolerant Core Services

probe monitor

accesscontrol

cryptokey

services

Routing Localization Clock Synch

6/32

Secure Network Layer

RemoteRemoteTransactionsTransactions

LocalLocalTransactionsTransactions

DKS

SGFP

TKEP

Application

Intra-GroupCommunications

Inte

r-G

rou

pC

om

mu

nica

tion

s

GKMP

pack

et-b

y-pa

cket

prot

ectio

n

secu

re

sess

ion

in-n

etw

ork

proc

essi

ng

aggr

egat

ion

8/32

Attack-Tolerant Localization

Key

Management

& Sharing

Key

Management

& Sharing

IntrusionDetectionIntrusionDetection

Program

Integrity

Verification

Program

Integrity

Verification

Attack-Tolerant Core ServicesAttack-Tolerant Core Services

probe monitor

accesscontrol

cryptokey

services

Routing Localization Clock Synch

Anomaly-basedAnomaly-based

IntrusionIntrusion

DetectionDetection

Attack-TolerantAttack-Tolerant

LocalizationLocalization

(VeIL)(VeIL)

17/32

Localization in Sensor NetworksTo assign locations to sensors consistently with measured distances

as well as reference locations from anchors

No

n-M

alic

iou

sE

nvi

ron

me

nt

No

n-M

alic

iou

sE

nvi

ron

me

nt

Ranging

• RSS• TOA• TDOA• AOA

Range-Free

• Centroid, APIT, …+ Cost-effective– High anchor density– High Tx power

Less Anchor-Dependent

• Multi-Dimensional Scaling• Iterative MDS• Mobile anchors• Hop counting, …

Ho

sti

leE

nvi

ron

me

nt

Ho

sti

leE

nvi

ron

me

nt

Authentication• Digital signatures, Tesla– Non-cryptographic attacks ?

Statistical Approaches

Specialized Anchors– Powerful anchors

– Anchor-provided information only– Inadequate use of network

characteristics

Verification of location/distance

18/32

Proposed Approach

Malicious/compromised devices propagate

wrong information about locations or distances

Malicious/compromised devices propagate

wrong information about locations or distancesTHREAT

• No cryptography needed • Use of spatio-temporal correlation among sensors

• No cryptography needed • Use of spatio-temporal correlation among sensors

KEY IDEA

HOW ? Iterative Location Update• Exchange locations (in BEACON pkts) with neighbors

• Refine location estimates

Cooperative Anomaly Detection• Manage compact profile of normal localization behavior

• Detect/locate/reject (sources of) attacks

19/32

Soft-Tamper Proofing via PIV

Key

Management

& Sharing

Key

Management

& Sharing

IntrusionDetectionIntrusionDetection

Program

Integrity

Verification

Program

Integrity

Verification

Attack-Tolerant Core ServicesAttack-Tolerant Core Services

probe monitor

accesscontrol

cryptokey

services

Routing Localization Clock Synch

ProgramProgram

IntegrityIntegrity

VerificationVerification

24/32

Why PIV ?V

eri

fyin

gP

rog

ram

Inte

gri

tyV

eri

fyin

gP

rog

ram

Inte

gri

ty Digitally Signed Programs• Short digest / signature

makes it easy to replay

Genuinity Testing, SWATT• Random memory transversal• Only probabilistic guarantee

Inappropriate for Sensors

OUR APPROACH

Controlled Manufacturing: Boot & Main Codes

Mobile Agent as Verifier

Randomized Hash Function

Pro

tect

ing

Pro

gra

m It

self

Pro

tect

ing

Pro

gra

m It

self

“Defenseless” Once Analyzed

Code Obfuscation• No perfect obfuscation• “Determined” attackers ?

Result Checking• High run-time overhead

Self-Checking• Hash computation code

& hash values ?

Self-Decrypting Programs• High run-time overhead• Decryption routines ?

25/32

PIV Overview

PIV Server Sensor

Main Code

Data(init’ed randomly)

Sensor Program

Boot Code

Initialize

Hash

hash result

Verify hash result

VrfyingVrfying

Create random Hash

pass

fail

LockedLocked

Boot CodeBoot Code

ActivatedActivatedMain CodeMain Code

Boot Code

26/32

PIV Architecture

PIV SERVER SENSOR

AUTHENTICATION

SERVER

Requestauthenticati

onof PIV Server

success/ fail

VerificationProtocol

27/32

Compatible with GKMPGroup-Heads as PIVS

PIVS/AS periodically floods its whereabouts

PIV_DB

• successfully-verified IDs• attributes like locations

Verification ProtocolSENSOR

PIV SERVER

Initialize

SendPIVC

AckPIVC

RequestVerification

NotifyVerification

Activateor Lock

Boot CodeBoot Code

PIV Code

StartPIVC

PIV CodePIV Code

Boot CodeMain CodeMain Code

PIV Code

28/32

if RequestVerification received late, Terminate PIV;

if verification success,Register in PIV_DB;

else,Ask neighbors not to relay packets;Renew GK;

LiSP: Unified, Energy-Efficient Security Framework

Key

Management

& Sharing

Key

Management

& Sharing

IntrusionDetectionIntrusionDetection

Program

Integrity

Verification

Program

Integrity

Verification

Attack-Tolerant Core ServicesAttack-Tolerant Core Services

probe monitor

accesscontrol

cryptokey

services

Routing Localization Clock Synch

Summary of LiSP

GKMPGKMP

Designed for local transactions

Efficient, robust re-keying

Loose clock synchronization

Designed for local transactions

Efficient, robust re-keying

Loose clock synchronization

PIVPIV

Software-based prevention of physical attacks

Complete verification framework

High-level security at a low cost

Software-based prevention of physical attacks

Complete verification framework

High-level security at a low cost

DKS / SGFP / TKEPDKS / SGFP / TKEP

Tailored to remote transactions

Secure, attack-tolerant routing

Symmetric-cipher-based key setup protocol

Tailored to remote transactions

Secure, attack-tolerant routing

Symmetric-cipher-based key setup protocol

VeILVeIL

Attack-tolerant localization

Anomaly-based intrusion detection tailored to localization

Spatio-temporal correlation

Attack-tolerant localization

Anomaly-based intrusion detection tailored to localization

Spatio-temporal correlation

Concluding Remarks Real-time and embedded is now everywhere and everyone’s

business! Challenges:

Fast design-to-market is essential Just commercial hypes w/o fundamental research? Minituralization, ruggedness, energy-efficiency, cost in addition to right kind of

QoS Optimization of QoS tradeoffs QoS tailored to apps, end-systems and their networking Heterogeneity and interoperability of end-systems and network protocols Protection of privacy and digital rights Usability and education Social impact

=> Don’t worry about your job security!