We are starting a new topic in CS146a: security.
In preparation for the security lecture read Chapter 11, Section A
(Introduction to secure systems) and Appendix 11-A
(Cryptography as a building block for secure systems).
For class discussion read Appendix 11-C (War Stories: Protection System Failures)
a collection of stories about security holes in suposedly-secure systems.
Some of the security problems are due to stupidity, but many emerged even though the designers were smart and had the best intentions.
Read them all through.
Then, for your reading assignment:
Please reread (from Chapter 11 Appendix C) sections 5.2 (Nonobvious Trust (TOCTTOU)), 5.3 (Virtualizing the DMA (TOCTTOU 2)), 11.1 (But I Thought It Was Secure), and 16 (Framing Enigma) and identify the principles from section A.4 of chapter 11 that were violated in these three case studies.
Read Chapter 11 up to and including 11.C (Authentication).
Authentication of requests amounts to answering the question which principal is making the request. Almost any security policy requires an answer this question. Today we study mechanisms for authentication.
In addition, please read Ken Thompson's "Reflections on Trusting Trust" available online. Do not be deceived by the shortness of this paper -- it is very deep and requires a lot of thinking and understanding, but it is also fun, once you get the hang of it. Keep this in mind as your prepare an answer to the following question:
Given that there are currently many different C compilers, both commercial and open source, discuss whether or not you can ensure that a C program that you write is free of the trojan horse described in the paper. In order to answer this question, you might want to think about what compiler(s) were used to compile the compiler(s) that you use and any common ancestry (code reuse) that they might have. You should discuss how much confidence you have that your program is trojan-free and whether or not this requires trust in any entities.
We are covering material on Confidentiality and Authorization. In preparation please read sections D and F of Chapter 11 in the K&F draft. We will study how to provide confidentiality of the content of messages that are sent over untrusted networks and mechanisms to perform authorization (i.e., deciding which principles are allowed to perform the requested operation).
In addition, please read "Why cryptosystems fail" by Ross Anderson. You may wish to skim the abstract, introduction, and conclusion first, because they will help you to focus on the parts of the paper that support the author's main claims. As always, you should read critically and be on the lookout for additional gems, and for arguments that are missing or whose framing de-emphasizes certain points.
This paper is about a philosophy of cryptosystem design, with a focus on their use in financial institutions, and particularly in ATM (Automated Teller Machine, not Asynchronus Transfer Mode) networks. Although it may not be immediately obvious, this paper is closely related to other papers we have read, such as the "Therac-25 paper". Think about these connections as you read.
Over half of the paper is devoted to examples of ways in which ATM networks could fail or have failed. This part of the paper is very entertaining, but it can be difficult to keep the big picture in mind while reading about the individual exploits and problems. Pay attention to the section headings (which you may wish to skim before diving into the text) in order to keep your bearings. For each incident, before moving on, spend a few moments thinking about the lessons that it teaches, and how the problem could have been avoided.
Here are some specific issues to think about while you are reading.
Your reading report will answer one of the questions raised in issues marked with a (*) above - you get to choose which one!
The final CS146a class discusses Butler Lampson's classic paper "Hints for Computer System Design". This paper presents about two dozen general rules of thumb that experienced system designers have found helpful in building functional, fault-tolerant systems with acceptable performance. Some of Lampson's rules may seem obvious to you. Don't be misled by their apparent simplicity: they embody deep ideas, and it is all too easy to forget them while in the throes of a project. (And even if they are obvious, they are well worth collecting and repeating.)
Start out by reading the conclusion of the paper, and then follow the advice in its first sentence: read the paper in small pieces, over time, so that you can fully absorb its lessons. You will get less from the paper if you read it all at once.
You are likely to be unfamiliar with many of the systems discussed in the examples. It is not necessary to understand every example, but you should understand in detail at least one of the examples for each hint. Then, for each hint you should think of at least one example of a use (and perhaps also a misuse) of the hint from one of the readings. In addition, think about your projects: how did you follow (or not) the hints? You might also think about when the hints are not applicable, and how you can tell when that is the case. Overall, the collection of hints should help you to synthesize the lessons you have learned during the semester.
System aphorism of the week
Engineering is the art of modeling materials we do not wholly
understand, into shapes we cannot precisely analyse so as to withstand
forces we cannot properly assess, in such a way that the public has no
reason to suspect the extent of our ignorance. (Dr. A. R. Dykes,
British Institution of Structural Engineers, 1976)
CS 146a Handout 10, issued November 16, 2007