On Securing Networked Real-Time Embedded Systems Kang G. Shin The University of Michigan.
-
Upload
cora-strickland -
Category
Documents
-
view
217 -
download
0
Transcript of On Securing Networked Real-Time Embedded Systems Kang G. Shin The University of Michigan.
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
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!