Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSCI1600: Embedded and Real Time Software

Similar presentations


Presentation on theme: "CSCI1600: Embedded and Real Time Software"— Presentation transcript:

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


Download ppt "CSCI1600: Embedded and Real Time Software"

Similar presentations


Ads by Google