Transcript JXTA Technology - NC State University

On Securing Networked
Real-Time Embedded
Systems
Kang G. Shin
The 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 a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Securing OS
QuickTime™ and a
TIFF (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 endsystems 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
Secure Embedded 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
Trust relationships
App
App
App
App App App
OS
HW
Hierarchical (e.g., TCPA)



vs.
OS
HW
Free for all
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?
Threat Model: “Software Privacy”
OS is malfunctioning
OS tries to be unethical
Faulty OS
Wily OS
Poor quality
of system
service
Information
leakage
App1
App2
Application
abusing
App4
App3
code/data encrypted

App4
App1
App2
App3
code/data encrypted
Meaning of “untrusted” OS


Observation,
tampering
OS’s quality of service, observation and tampering
Privacy: a process can conceal code/data from others,
including malfunctioning/willy OS
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
model as “software privacy”
 Solution should be complete
 Threat
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
L2
Cache
Encryption
Hardware
Physical security
perimeter
CPU
Register
File
PID
Main Memory
Key File




Cryptographic hardware + MMU = secure processor
Content of the main memory is encrypted
Typically, per-process encryption
A context switch requires special care
Software Distribution Model
Public key
encrypt using
purchaser’s Kp+
Public key Kp+
Distributor’s
randomly chosen key
Symmetric key Ks
Private key Kp{Ks}Kp+
Encrypted
software
Customer side



Key delivery
Content delivery
Software
master copy
Encrypt
using Ks
Encrypted
software
Software distributor side
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-)
A Possible Solution
σ
µ
process-key
key-page
key file
Machine state
Instructions
Grant
Revoke
Map
Unmap
Alloc
Free
: Privileged instructions and operating system data structure
: Secured data structure (protected by hardware)
Here Come Mobile Worms!
 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!, cont’d
 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
Modeling and Containment Challenges
 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
Agent-based Malware Modeling (AMM):
An Approach
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
Challenges in Sensor Networks
Harsh, hostile, unattended
deployment
Battery-powered, nonrechargeable
A large number of nodes
Self-organizing/healing
Need High-Level Security
with Limited Energy Budget
=>LiSP
1/32
Common Objectives
Lightweight
Attack-Tolerant
To prolong network lifetime
Self-healing – detect &
identify attackers
Symmetric-key ciphers,
crypto hash functions
Cooperative
Collaboration &
Cooperation among
sensors/protocols
Gracefully tolerate attacks
Energy-aware
Security
Compatible
Existing security mechanisms
Flexible
Security & energy
tradeoffs
Scalable
To large network size
2/32
Taxonomy of Attacks
• Capture victims
• Reverse-engineer & reprogram programs
• Re-deploy compromised sensors
Physical Attacks
• Multiple fictitious IDs (locations)
Sybil Attacks
Wormhole Attacks
Radio (Jamming) Attacks
Outsider / 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
3/32
Attack-Prevention Approach
THREAT
Attack on Traffic
DEFENSE
Key Sharing
•
•
•
•
• Eavesdropping
• Traffic replay,
modification,
injection
• Service disruption,
DoS, Sybil, …
Attack on Program
The adversary can
• capture
• reverse-engineer
• re-program
• Clone sensor
device(s)
Globally
Group-based
Pairwise
Combined
Pre-deployment
of keys
H/W
Tamper
Resistance
S/W
•
•
•
•
Obfuscation
Result checking
Self decryption
Self checking
PROBLEM
• Sensor
compromises ?
SOLUTION
Group-based
Key Management
• Re-keying ?
• Processing &
communication
overheads ?
Protection of
program itself 
Defenseless
once broken
Distributed
Key Sharing
Soft
Tamper-Proofing
via
Program-Integrity
Verification
4/32
• Gracefully tolerate attacks
• Detect, identify & remove sources of attacks
OBJECTIVES
Attack-Tolerance Approach
SERVICE
Routing
Localization
Clock
Synchronization
HOW ?
SOLUTION
Use
Secure
Geographic
Forwarding
Protocol
Distributed
Key
Sharing
Exploit
Spatio-Temporal
Correlation
Temporal-Key
Establishment
Protocol
Verification for
Iterative
Localization
Attack-Tolerant
Clock Synch
Protocol
5/32
LiSP Architecture
Key
Management
& Sharing
Intrusion
Detection
probe
Program
Integrity
Verification
monitor
crypto
key
access
control
services
Attack-Tolerant Core Services
Routing
Localization
Clock Synch
Security & Energy Tradeoffs
6/32
Secure Network Layer
Intra-Group
Communications
DKS
session
secure
protection
GKMP
Remote
Transactions
packet-by-packet
Local
Transactions
aggregation
in-network processing
Inter-Group
Communications
Application
TKEP
SGFP
8/32
Attack-Tolerant Localization
Key
Management
& Sharing
Intrusion
Program
Integrity
Verification
Anomaly-based
Detection
Intrusion
probe
monitor
Detection
crypto
key
access
control
services
Attack-Tolerant
Attack-Tolerant
Core Services
Routing
Localization
Localization
(VeIL)
Clock Synch
17/32
Localization in Sensor Networks
Hostile
Environment
Non-Malicious
Environment
To assign locations to sensors consistently with measured distances
as well as reference locations from anchors
Ranging
•
•
•
•
RSS
TOA
TDOA
AOA
Range-Free
Less Anchor-Dependent
• Centroid, APIT, …
+ Cost-effective
– High anchor density
– High Tx power
Authentication
• Digital signatures, mTesla
– Non-cryptographic attacks ?
Specialized Anchors
– Powerful anchors
•
•
•
•
Multi-Dimensional Scaling
Iterative MDS
Mobile anchors
Hop counting, …
Statistical Approaches
– Anchor-provided information only
– Inadequate use of network
characteristics
Verification of location/distance
18/32
Proposed Approach
THREAT
Malicious/compromised devices propagate
wrong information about locations or distances
KEY IDEA
• No cryptography needed
• Use of spatio-temporal correlation among sensors
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
Intrusion
Detection
probe
Program
Program
Integrity
Integrity
Verification
Verification
monitor
crypto
key
access
control
services
Attack-Tolerant Core Services
Routing
Localization
Clock Synch
24/32
Protecting
Program Itself
Why PIV ?
Code Obfuscation
• No perfect obfuscation
• “Determined” attackers ?
Result Checking
• High run-time overhead
Self-Decrypting Programs
• High run-time overhead
• Decryption routines ?
Self-Checking
• Hash computation code
& hash values ?
Verifying
Program Integrity
“Defenseless” Once Analyzed
Digitally Signed Programs
• Short digest / signature
makes it easy to replay
Genuinity Testing, SWATT
• Random memory transversal
• Only probabilistic guarantee
OUR APPROACH
Controlled Manufacturing:
Boot & Main Codes
Mobile Agent as Verifier
Randomized Hash Function
Inappropriate for Sensors
25/32
PIV Overview
Sensor Program
fail
Boot Code
Locked
Vrfying
pass
Activated
Main Code
Data
(init’ed randomly)
PIV Server
Sensor
Initialize
Create random Hash
Hash
hash result
Verify hash result
26/32
PIV Architecture
Compatible with GKMP
Group-Heads as PIVS
AUTHENTICATION
SERVER
PIVS/AS periodically floods
its whereabouts
• successfully-verified IDs
• attributes like locations
Request
authentication
of PIV Server
success
/ fail
PIV_DB
PIV SERVER
Verification
Protocol
SENSOR
27/32
Verification Protocol
Initialize
PIV SERVER
SendPIVC
AckPIVC
RequestVerification
SENSOR
Boot
Main Code
StartPIVC
Activate
or Lock
NotifyVerification
if RequestVerification received late,
Terminate PIV;
PIV Code
if verification success,
Register in PIV_DB;
else,
Ask neighbors not to relay packets;
Renew GK;
28/32
Summary of LiSP
LiSP: Unified, Energy-Efficient Security Framework
GKMP
Intrusion
PIV
Key
Program
Detection Software-based
Management
Integrity
Designed
for local transactions
prevention of
physical attacks
& Sharing
Verification
monitor
Efficient,
robust re-keying probe
Loose clock synchronization
crypto
key
Complete verification framework
access
High-level security
at a low cost
control
DKS / SGFP / TKEP
Tailored to remote transactions
Secure, attack-tolerant routing
VeIL
Attack-tolerant localization
services
Anomaly-based intrusion
Attack-Tolerant Core Services
detection tailored to localization
Symmetric-cipher-based key
Routing
Localization Spatio-temporal
Clock Synch
setup protocol
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!