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