Important Dates

• Take-home final exam, May 13-15
• Project presentations
  • May 6: Chang Liu and Xaio Wang; Andrew Ruef
  • May 8: Nate Parsons; Kris Micinski
  • May 13: James Parker
• Project final writeup, May 21

Class notes

• 28 Jan, Overview of the course
• 30 Jan, War in Memory; here is the scribe report (Andrew Ruef).
• 4 Feb, Low-level attacks and ROP; here is the scribe report (Nate Parsons)
• 6 Feb, Randomization-based defenses: ASLR and JIT code diversification; here is the scribe report (Kris Micinski)
• 11 Feb, Control-flow integrity: Scribe report (James Parker)
• 18 Feb, Code injection attacks: Scribe report (Aseem Rastogi)
• 20 Feb, Information flow security: Scribe report (Xiao Wang)
• 25 Feb, Noninterference and leakage (forgot to scribe!)
• 27 Feb, Dynamic info-flow tracking: Scribe report (Chang Liu)
• 4 Mar, Information flow control and exceptions: Scribe notes (Nate Parsons)
• 6 Mar, Declassification: Scribe notes (Andrew Ruef)
• 25 Mar, Facets and privacy policy enforcement: Scribe notes (Nate Parsons)
• 27 Mar, Keyboards and PC side channels: Scribe notes (Kris Micinski)
• 1 Apr, Timing and traffic channels: Scribe notes (James Parker)
• 3 Apr, Models of noninterference: Scribe Notes (XIao Wang)
• 8 Apr, Quantifying information flow (QIF): Scribe Notes (Chang Liu)
• 10 Apr, Computing QIF, and beliefs in QIF: Scrive notes (James Parker)
• 17 Apr, Analyses to find vulnerabilities: Scribe notes (Andrew Ruef)
• 22 Apr, Authenticated data structures (generically): Scribe notes (Xiao Wang)
• 24 Apr, Abstract interpretation and obfuscation: Scribe notes (Max Potasznik)

Syllabus

OS-level and hardware protection cannot solve the security problem alone.  We need ways to establish the trustworthiness of software, to augment or even replace these mechanisms.  For example, OS-level mechanisms fail to protect against SQL injections, cross-site scripting, stack smashing, and other attacks.

In this class we consider vulnerabilities in software, and means to address them. Our focus will be on software-oriented techniques, rather than OS-level and hardware techniques (though these will not be ignored). In particular, we will consider novel programming languages, programming language analyses (both on the source code, and as instrumentation on the running program), and programming tools that can be used to identify and address security issues.

Most of the class will consist of reading and discussing papers in the research literature. The discussion site has the reading list and blog software. It's not completely filled out; here is a preliminary reading list (a prefix of which is on the discussion site) .

Prerequisite: There is no official pre-requisite for this class (beyond an undergraduate CS degree); we will attempt to make it largely self-contained. We will be reading some technical papers from the programming languages research literature, so having taken CMSC 631 (or taking it concurrently) will be helpful. That said, we will review programming languages concepts crucial for understanding particular papers prior to reading them. Contact the instructor if in doubt.

Grading: Graded work is as follows:

• Class Participation (40%), in two parts: (1) written reviews of the papers we read; (2) attendance and participation in class; (3) scribed reports of class discussion.
• Project (30%). Students will propose projects approximately one month into the semester, to be completed by the end of the semester. Projects, done individually or in groups, will attempt a non-trivial study or implementation of a programming language, analysis, or tool. In the best case, these projects will be a prelude to published papers. More details on the project will be made available during the semester. Groups present their projects at the end; grading criteria for presentations is given below.
• Final Exam (30%). There will be a comprehensive final exam, which will count for comp credit.

Paper reviews (comments) and class participation: Students will be required to submit an insightful comment or question about each paper by 9am the day of class. Insightful comments are not redundant with prior comments, so consider starting early, or if late, comment on comments. Good questions can point out things not made clear in the paper. Paper comments are generally given scores of 0, for missing or showing no evidence of having read the paper, 1, for minimal effort or a not-insightful summary, and 2, for actively insightful. There is a sweet spot of comment length that approximates a paragraph: one or two sentences is too short to develop an idea, three or four paragraphs is too long to describe a coherent idea well.

Here is some useful advice about how to read papers. Once you get in the groove, you should expect to spend 1-3 hours per paper (you do not need to understand every detail, especially for the longer papers).

• How to read a technical paper by Jason Eisner (JHU)
• How to Read a Paper by Michael Mitzenmacher (Harvard)
• Efficient Reading of Papers in Science and Technology by Michael J. Hanson (and updated by Dylan J. McNamee)

Scribes: Each person will act as a scribe at several points during the semester, taking notes on the class discussion to be published on the course web site. The basic format for the notes should be the following:

• Summary: This is a one-to-two paragraph summary of the key points about the papers that are introduced at the start of class.
• Questions: Collects technical questions and answers people have about the paper that warranted clarification
• Criticisms: What parts of the paper did people criticize, and which of these garnered consensus? Critcisms could be about algorithms, benchmarks, claims in general, etc.
• Ideas: What ideas for further research came up during the discussion?

Presentations: Students making presentations will be graded on the following criteria:

• understanding: does the presenter understand the material?
• thoughtfulness: does the presenter have insights and opinions beyond what was in the paper?
• background/perspective: did the presenter read background papers?
• clarity: can the audience understand the presentation? is the "big picture" clear? are there useful examples?
• materials: do the slides or use of blackboard illustrate and support the talk? are there diagrams to help convey the technicalities? (when your talk gets into deep territory, a diagram is worth 10K words)
• delivery: has the the presenter practiced?
• non-regurgitation: did the presenter do something beyond simply typing sections of the paper as bullet points? did the presenter motivate the ideas in their own words or just state ideas from the paper verbatim?
• answering questions: can the presenter handle questions from the audience?

Academic Dishonesty: The university policy on academic dishonesty is strictly followed. All graded materials (whether exams, summaries, presentations, or projects) must be strictly individual efforts. In the case of a group project or assignment, only collaborations within the group are permitted.

Web Accessibility