CSCI1600: Embedded and Real Time Software

1. CSCI1600: Embedded and Real Time Software Lecture 35: Fault Tolerance & Security Steven Reiss, Fall 2016

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

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

4. Responding to Faults • Fault confinement • 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 Lecture 35: Security

5. Fault Avoidance • Don’t write buggy code • Serious testing, defensive programming • Verification & Validation • Avoid running devices at their limits Lecture 35: Security

6. Fault Detection and Recovery • 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

7. Redundancy • Triple modular redundancy • 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

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

9. Fault Recovery • What to do if something goes wrong • 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

10. Fault Recovery • Self-checking software • With checkpoint and rollback • Correct data defects in memory and continue • Adaptive 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. 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 • One data partition • All data is soft-state Lecture 35: Security

12. Security • Why worry about security in an embedded app? Lecture 35: Security

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

14. Remote Interfaces • If the device has no remote interface • Then changes require physical access • 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

15. Remote Interface • Unauthorized access • 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

16. 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

17. 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

18. Code Attacks • What is a buffer overflow • What can you do with it? Lecture 35: Security

19. 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[0 .. 999] CS132 Lecture 26: Security II

20. 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

21. 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

22. 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

23. Public Key Cryptosystems • 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

24. 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

25. 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

26. 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

27. Other Attacks • Disk attacks • Large files • File path attacks • XSS attacks • SQL injection Lecture 35: Security

28. Next Time • Course Review Lecture 35: Security