Download presentation
Presentation is loading. Please wait.
1
CSCI1600: Embedded and Real Time Software
Lecture 33: Fault Tolerance & Security Steven Reiss, Fall 2017
2
Fault Tolerance We’ve talked about proving properties of systems
This can’t always be done And even so, it is an approximation Assumes program is correct Assumes real world model is correct Assumes computer and other hardware work correctly And you can’t prove everything Embedded systems need to be fault tolerant No other recourse after failure Lecture 35: Security 11/13/2018
3
Fault Modeling What can fail How things can fail (failure modes)
Why things might fail (random or combined) Faults might be permanent, intermittent, or transient Faults might show up in different ways Lecture 35: Security 11/13/2018
4
Responding to Faults Fault confinement Fault detection and location
Limit the effect of a fault to a local subsystem Defensive programming Fault detection and location Self tests If transient, get enough information for later analysis Fault masking Hide the effect of faults Retry Transient faults might go away Disk and memory problems may be transient Java XML parser has transient faults Lecture 35: Security 11/13/2018
5
Fault Avoidance Don’t write buggy code Verification & Validation
Serious testing, defensive programming Verification & Validation Avoid running devices at their limits You will still have faults Lecture 35: Security 11/13/2018
6
Fault Detection and Recovery
Systems that need to be fault-tolerant Extreme defensive programming Error checking codes (checksums) for messages Self-checking and fail-safe logic Watchdog timers and time-outs Consistency and capability checks Duplication (redundancy) This is important in critical, unsupervised systems Lecture 35: Security 11/13/2018
7
Redundancy Triple modular redundancy This fails when
Hardware is replicated three times Outcome of each module (high-level routine) is a vote If 2 agree on the answer, it is chosen This fails when All 3 disagree (fail-stop) Two modules fail together (byzantine) The voting mechanism fails Can handle k failures by having higher number of modules Lecture 35: Security 11/13/2018
8
Space Shuttle Redundancy
Five computer implement the system Four make up the primary system Normally in command; Simultaneously execute identical code Synchronize on I/O; Actuation is a physical vote Priority-based OS The fifth system is the backup Completely independent implementation Normally operates in listen-mode; Requires a manual switch-over OS is time-sliced, not priority scheduled Still have problems Same language, same compiler Lecture 35: Security 11/13/2018
9
Fault Recovery What to do if something goes wrong Watchdog timer
Keep the system running Put the system into a stable state Watchdog timer Monitor routine of sorts Task code periodically sets a flag Watchdog (high priority) checks and unsets the flag If flag is unset, restart the system Care needed to not make things worse Lecture 35: Security 11/13/2018
10
Fault Recovery Self-checking software Safe backup state
With checkpoint and rollback Correct data defects in memory and continue Adaptive software “Learning” software Safe backup state Failure isn’t just CPU failure Might not want to reboot from stored state Reset-reboot switches Lecture 35: Security 11/13/2018
11
Fault-Based Disk Partitioning
Flash-based devices Four disk partitions Boot partition that is never touched Two OS partitions Usually mounted read-only Upgrades are written to the spare partition Upgrade partition is then remounted read-only and marked clean Boot partition will not boot from unclean partition Can switch over to other partition if necessary One data partition All data is soft-state Lecture 35: Security 11/13/2018
12
Security Why worry about security in an embedded app?
Examples of security problems Lecture 35: Security 11/13/2018
13
Security Problems Allowing external users to break the device
Allowing unauthorized control Allowing others to take over the device Unintentional usage Providing access to private information Lecture 35: Security 11/13/2018
14
Threat Models The first step toward security is understanding threats
What are you trying to prevent What data/actions are important Who are you trying to protect Who are the potential attackers Cost model for threats Anything can be prevented, but at a cost Anything can be attacked, but at a cost Lecture 35: Security 11/13/2018
15
Remote Interfaces If the device has no remote interface
Then changes require physical access Is this true? Physical access implies one can do anything Still want to protect users from themselves If the device has a remote interface Can be direct (socket connection for example) Can be web-based (using browser) Lecture 35: Security 11/13/2018
16
Remote Interface Unauthorized access Illegal inputs
Bad checking of logins Bad checking of permission levels Illegal inputs That can break the code That can change the code Man-in-the-Middle attacks Web Interface XSS attacks Lecture 35: Security 11/13/2018
17
Logging In Common operation
Should be easy What are the problems? What are the operations to be concerned with? Registration (initial name & password) Log in (provide name & password to validate) Access while logged in CS132 Lecture 26: Security II 11/13/2018
18
Logging In: Threat Model
Spoofing URLs Sending lots of requests Wi-Fi snooping Internet snooping Reading logs Man-in-the-middle attacks Phishing attacks Brute force Loss of database (SQL injection attack; stolen laptop) CS132 Lecture 26: Security II 11/13/2018
19
Code Attacks What is a buffer overflow What can you do with it?
Lecture 35: Security 11/13/2018
20
Buffer Overflow Attack
Code: void function(char* text) { char buf[1000]; strcpy(buf,text); // do some editing of buf // save result } Stack (high to low) 8888: <ptr to text> 8884: <return address> 8880: <old stack ptr> 7880: buf[ ] CS132 Lecture 26: Security II 11/13/2018
21
Preventing Buffer Overflow
Check sizes of data before putting in array Reads, copies, inputs Randomize code locations between runs Don’t let data pages be executable Static checkers CS132 Lecture 26: Security II 11/13/2018
22
Encrypted Connections
Encrypt all communication Simpler solution than trying to encrypt password Between the browser and the server Handles some of the issues raised with passwords Handles other problems as well Credit card numbers and other private information Encrypted communications are relatively standard Clients needs to agree on how to encode/decode Agreeing on an algorithm for encoding/decoding Agreeing on a key for that algorithm CS132 Lecture 26: Security II 11/13/2018
23
Standard Encryption Both parties agree on a key K
F(K) and F-1(K) are easy to compute If you know K But are difficult if you don’t know K May even be done in hardware Standard encryption functions available DES is probably the most common Problem: agreeing on K CS132 Lecture 26: Security II 11/13/2018
24
Public Key Cryptosystems
Originator has two pieces of information X and Y F(string,X) = encoded string F-1(string,X) is difficult to compute F-1(string,X,Y) is easy to compute Examples Y,Z are 200 digit primes, X is Y*Z Create a string using X such that string can only be decoded knowing the factors of X Other examples are possible This is often used as part of a secure protocol Agreeing on a key for a more secure encoding CS132 Lecture 26: Security II 11/13/2018
25
Browser-Server Communication
Can use encrypted communication in a web app HTTPS represents an encrypted (secure) connection HTTPS is just like HTTP Except that all data passed back and forth is encrypted Browser and server agree on a key Encryption is then done based on this key This is handled by the Secure Sockets Layer (SSL) SSL is not specific to web applications CS132 Lecture 26: Security II 11/13/2018
26
HTTPS Connections Browser makes a connection to the server
SSL handshake protocol Browser sends and requests a certificate Certificates are effectively keys that can be verified as authentic This is one way public key systems are used Server replies with a certificate of its own SSL change cipher protocol Browser and server use their certificates to agree on a key Again using a variant of public key systems Communication is done securely using that key Key is only used for this particular session CS132 Lecture 26: Security II 11/13/2018
27
HTTPS Usage If you are sending confidential information
Even just passwords Especially credit card numbers, etc. You should use HTTPS OPENSSL and other implementations exist Typically built into server and browser Different port used for secure communication Integrated into Apache using Mod_SSL for example Problem: Obtaining a certificate CS132 Lecture 26: Security II 11/13/2018
28
Side Channel Attacks Getting information from power usage, radiation, etc. Lecture 35: Security 11/13/2018
29
Server Attacks Disk attacks Information flow XSS attacks SQL injection
Large files File path attacks Information flow XSS attacks SQL injection Lecture 35: Security 11/13/2018
30
Consider Self-Driving Cars
What is the threat model? What can be done to prevent threats? Lecture 35: Security 11/13/2018
31
Next Time Queueing Theory Lecture 35: Security 11/13/2018
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.