Embedded Systems Security

Embedded Systems Security:
(Why its difficult and what we can do about it)
Malachi Jones, PhD
Software Engineer

About me (Cyber-security Background)
2
• Intel Corporation (Summer 2011)
– Software security internship
– Designed/implemented an authentication method for mobile embedded devices
• Georgia Tech (2007-2013)
– Security research collaboration between Georgia Tech (GT) and University of
California Santa Barbara (UCSB)
– PhD thesis: “Asymmetric Information Games and Cyber Security”
Giovanni Vigna, PhD
Security Researcher
Joao Hespana, PhD
Game Theorist
Jeff Shamma, PhD
Game Theorist
Georgios Kotsalis, PhD
Game Theorist
Malachi Jones, PhD
Security Researcher

Outline
5
• Motivation
• Cyber Security Overview
• Embedded Systems Security
– Networked Systems
– Embedded Systems OS
• Principles for Designing Secure Software
– Minimal Implementation
– Component Architecture
– Independent Expert Validation
• Conclusion
• Additional Resources

Motivation
6
• Why should embedded security be important to YOU (and your loved ones)?
Critical Infrastructure
(Nuclear Power Plant)
Life Critical Systems
(Pace Maker)
Transportation Systems
(Flight Control)
Financial Infrastructure
(Banking & Investing)
Information Systems
(Patient MRI information)
Consumer Products
(Wireless Router)

Motivation
7
• What could possibly happen if your home router was
attacked by a hacker?
– Step 1: Hacker gains access to router settings
– Step 2: Changes DNS settings on router
– Step 3: Router now talks to hacker’s server to resolve
name address
– Step 4: www.yourbank.com now resolves to an IP
address of the hacker’s server
– Step 5: You think you are entering login information for
your bank account, but you are handing it over to the
hacker.
– Step 6: pwn3d (Hacker speak for you’ve been owned)
• True story (DNSChanger Trojan)

Main Takeaways
8
• Why is embedded security difficult?
– Economic/Business incentive to produce bad security products: Oftentimes
buyers (experts included) are unable to observe the difference in quality between
a good security product and a lemon.
– Increased software complexity: Linear growth in hardware/software content
creates non-linear growth in overall system complexity. Complexity breeds flaws.
– Security as an afterthought: Often financially and/or technically infeasible to
retrofit security capabilities to an embedded system that was not originally
designed for it

Main Takeaways
9
• How can we address these difficulties?
– Balance the tradeoffs: Strike a balance between security, performance, cost,
and schedule.
– Control complexity: Aspire for a minimal implementation that provides the
simplest solution to the problem with respect to tradeoffs (e.g. cost and schedule)
mentioned above
– Design in security from conception: Build in security from the start by following
well-established security-design principles and techniques
Theme of presentation

Cyber Security Overview
10
• Objectives of cyber security
– Confidentiality: Prevention of unauthorized access to resources
– Integrity: Prevention of modification or corruption of resources
– Accessibility: Prevention of attacks that would keep a resource from being
accessed or used according to its intended function

11
• Security topic areas include:
Cryptography Penetration Testing Monitoring &
Detection
Social Engineering Cyber Situational
Awareness
Security System
Design

12
• Cyber security principles
– Without physical security, there is no security: If the physical system is
compromised, so are the other components of the system that interact directly or
indirectly with the physical system
– Once “root”, always “root”: Once a system has been compromised, a hacker
can install “backdoors” to access the system with root privileges later
– Defense in depth: Complete prevention is impossible. Multiple layers of
prevention and monitoring are necessary to achieve the optimum degree of
protection (for a given budget).
– Kerckhoffs’s Principle: Assume the hacker knows the system. Corollary:
Security by obscurity is not secure.
– Weakest Link Principle: Weakest link in the system is the most likely part of the
system to be first attacked because it is the easiest

13
• What are some of the primary culprits for the abundant security
vulnerabilities found in most mainstream products?
Poor Implementation Flawed Design

14
• Why can it be rational to produce bad security products?
• Market for Lemons
– Paper written by the economist George Akerlof in the 1970s to discuss
information asymmetry.
– Information asymmetry: One party has better information than another party
– Main Idea: When buyers don't have as much information about the quality of the
products as sellers do, there will be severe downward pressure on both the price
and quality of product

15
• Market for cyber security “lemons”
– Buyers (security experts included) are often unable to distinguish a “good”
security product from a “bad” security product
– Difficult to evaluate a product’s claims when the source code and design
architecture are proprietary and kept private.
– Costs significant amount of money for an independent third party to evaluate
and test the product claims. Testing is also slow.
– Bottom line: Can be rational for companies to produce mediocre security
products because users and experts are likely to make their purchasing
decision on parameters (i.e. price) they can observe.
– Rare Exception: Secustick was exposed by Tweakers.net for not encrypting
data on USB drives when they claimed to have done so.

Embedded Security: Embedded Systems
16
• Definition: An embedded system is an electronic product that contains
a microprocessor (one or more) and software to perform some
constituent function within a larger entity
• Key Point: Embedded systems may be constrained by cost, memory,
energy, mass, and volume
• Examples
• What do all these embedded devices have in common?
Smart Meter Raspberry Pi Smart Phone Router

Embedded Security: Networked Systems
17
• What are the advantages of networked embedded systems?
• Remote management
– Monitor performance of devices deployed in the field
– Enables installation of patches or other software upgrades
– Execute a plethora of management duties
– Increases product lifetime, reliability, serviceability, and customer satisfaction
while reducing maintenance cost and total cost of ownership
• Example of remote management: Mars Pathfinder Mission

Embedded Security: Remote Management
18
• Mars Pathfinder Mission (1997)
– Malfunction was diagnosed down to a software defect during mission
– Priority inversion issue between communication tasks (medium priority),
meteorological tasks (low priority), and information bus thread (high priority)
– Patch to remedy defect by implementing priority inheritance was installed via
radio link from Earth
– Remote management saved the mission from disaster

Embedded Security: Remote Management
19
• Security implications of remote management
– Remote device management is the answer to the hacker’s wildest dreams
– The embedded system is imbued not only with internet access, but also a
means to remotely modify and patch software
• What could go wrong?
– Critical and widespread vulnerability in VxWorks OS discovered in 2010
– A debug communication port that provided remote diagnostics was used to
commandeer the system
– Using the debug interface, a remote attacker could read or write to any
memory location:
– Hacker could install malware and even replace the OS itself
– Key Point: Even if your software is perfect, you still have to take into account
the security of the third-party OS

Embedded Security: Operating Systems
20
• Why is the operating system important to security?
– Recall: Even with perfect software, the OS can allow the system to be vulnerable
to a cyber attack
– Operating system (OS) controls the resources of the embedded system (e.g.
memory and CPU)
– The OS has the power to prevent unauthorized use of resources

21
• Design decisions emphasize performance over security because
more profitable (Market for Lemons)
• Monolithic kernel: Popular OS design
– User applications able to access most services (TCP/IP, files, and I/O devices)
with a simple system call into kernel
– Services typically reside within a single process
• Microkernel: Secure OS design
– Implements services in separate processes
– Requires inter-process communication (added overhead)
– Extra context switching

22
Traditional Kernel (Monolithic) Microkernel (Implemented in MILS)

23
• Good News: A few OS technologies have taken a new approach to
embedded security that is based on a design concept originally
developed in the 1980’s.
• Design concept: Multiple Independent Levels of Security (MILS)
• Foundation of MILS-based embedded system is a special type of
microkernel called the separation kernel.

24
• Separation Kernel: A small microkernel that implements a limited set of
critical functional security polices that include data isolation, damage
limitation, and information flow
– Data Isolation: Data within partitioned applications cannot be read or modified by
other applications
– Damage limitation: If a bug or attack damages a partitioned application, this
damage cannot spread to other application
– Information flow: Information cannot flow between partitioned applications unless
explicitly permitted by the system security policy

Designing secure embedded systems
25
• Why not bolt on security after the fact?
• Key Concept: Often financially and/or technically infeasible to retrofit
security capability to a system that was not originally designed for it
• Think about the difficulty of retrofitting these systems:
• These systems can have a lifespan of 10+ years
• Moore's Law doesn’t apply!! (Very difficult to add/upgrade hardware)
Pace Maker Smart Meter Nuclear reactor
controller

Designing secure embedded systems
26
• Software assurance: Refers to the level of confidence that software
end user and other stakeholders have that security policies and
functions claimed by software are actually fulfilled
• Key Point: Simply meeting functional requirements does not achieve
the assurance required for security-critical embedded systems
• Principles of High Assurance Software Engineering [2]
– Minimal Implementation
– Component Architecture
– Independent expert validation
– Least privilege
– Secure development process

Designing secure embedded systems: Minimal Implementation
27
• Minimal Implementation
– Linear growth in hardware/software content creates non-linear growth in
overall complexity of the system
– Complexity increases nonlinearly because of the exponential increase in
interactions between functions and components
– Complexity breeds flaws, and those flaws can be exploited to breach the
system’s security
– Ideally: Implement the simplest system needed to solve the problem.
– Design Concept: Find a balance between schedule, performance, design,
and cost that doesn’t compromise the required security of the system

Designing secure embedded systems: Component Architecture
28
• Component Architecture
– Difficult/infeasible for a single engineer to understand every single line of code
of a large monolithic system
– Design Concept: Compose large software systems from small components.
Each component should be easily maintained by a single engineer who
understands every single line of code
– Design Concept: Safety and/or security enforcing functionality should be
placed into separate components that allow critical operations to be protected
from compromise by noncritical portions of the system

Designing secure embedded systems: Component Architecture
29
• Component Architecture
– Modern OS provides memory protected processes
– Design Concept: Designers should strive for a one-to-one ratio between threads
and processes
– Security/Performance Tradeoff: Threads are lighter weight than processes, but
processes can provide memory protection

Designing secure systems: Independent Expert Validation
30
• Independent Expert Validation
– Security claims are a dime-a-dozen (e.g. Secustick)
– Design Concept: Evidence of a secure system must be evaluated by
independent experts
– Anyone can produce a security design that is so clever, they can’t defeat it
– Very difficult to produce a design that is so secure, others can’t defeat it
– Independent experts provide another set of eyes that can spot security
vulnerabilities that the designers can’t see

Conclusion
31
“The art of war teaches us to rely not on the likelihood of the enemy’s not
coming, but on our own readiness to receive him; not on the chance of his not
attacking, but rather on the fact that we have made our position unassailable”
—The Art of War, Sun Tzu

Additional Resources
32
1. M. Jones, G. Kotsalis, and J. Shamma, “Cyber-attack forecast modeling and
complexity reduction using a game-theoretic framework,” in Control of Cyber-
Physical Systems (D. C. Tarraf, ed.), vol. 449 of Lecture Notes in Control and
Information Sciences, pp. 65–84, Springer International Publishing, 2013.
2. Kleidermacher, D. & Kleidermacher, M. (2012). Embedded Systems Security:
Practical Methods for Safe and Secure Software and Systems Development.
3. Ferguson, Niels, Schneier, Bruce & Kohno, Tadayoshi (2010). Cryptography
Engineering: Design Principles and Practical Applications. Wiley Publishing
4. Gebotys, C.H. (2009). Security in Embedded Devices. Springer
5. Anderson, R., "Why information security is hard - an economic perspective,"
Computer Security Applications Conference, 2001. ACSAC 2001.
Proceedings 17th Annual , vol., no., pp.358,365, 10-14 Dec. 2001

Embedded Systems Security

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Embedded Systems Security

Similar to Embedded Systems Security (20)

More from Malachi Jones

More from Malachi Jones (7)

Embedded Systems Security