ECE1776: Computer Security, Cryptography and Privacy


·                    Last week of presentations, next week we will present our project results.

·                    Lecture 8 on Network Security Posted

General Information

Instructor: David Lie, SF2001C

Course E-mail:

Grading Scheme:

1.      Paper Presentation 30%

2.      Project Proposal 5%

3.      Project Midterm Presentation 20%

4.      Project Research Paper 45%

Time: Tuesdays, 1-3PM

Location: BA 4164

Course Format

This course will primarily be a reading course.  Each week students are expected to read the assigned readings and discuss them.  Every week, general lecture style notes will be posted, and there will be an opportunity for students to ask questions, but no lectures will be given.  There will also be a course project due at the end of the semester.

Course Readings and Presentations

Students are expected to read the 3 papers assigned each week and come to class prepared to discuss the papers.  Each week a group of 2-3 students will present their views of the papers.  For each paper, one of the students will present pro’s for the paper, and the other will present con’s for the paper, and each student should be pro for at least one paper and con for at least one paper.  A good paper should present a new and practical solution/technique so solve an important problem.  It should also contain a critical evaluation of the merits of the idea, and clearly point out any flaws or shortcomings that could be solved in future work (of if they can be solved at all).  Finally, the paper should clearly indicate past work in the area, and indicate how their solution improves on the existing solutions.  For advice on giving presentations, refer here.


Each paper presentation should last approximately 20 minutes (for both presenters) and be in this general format:

  1. Summary of the paper (~10 minutes): You will summarize the objective of the paper, the proposed technique and the results/contributions the authors have presented.  If there is background required to understand the contents of the paper, the presenter should touch upon this as well.  Either the pro or con presenter can handle this part.
  2. The Pro presenter will explain what he/she thought was good about the paper, and argue for why the paper should have been accepted. 
  3. The Con presenter will then argue for why the paper should not have been accepted.


The presenters should meet before hand and discuss their views of the paper.  During the presentation some good questions to answer (this list is neither exhaustive nor are they applicable in all cases):

·                                Are the authors working on a real problem? 

·                                Did the authors miss any critical limitations in their paper?  Was the way they presented their evaluation honest and fair?

·                                Did the evaluation test the right aspects of the solution?  For example, did the presenters pick the right benchmark?

·                                Is the solution really novel?  Did the authors identify all related work or did they miss work that is very similar to theirs.  You should spend time doing an extended literature search for all papers (Google is your friend).

·                                Did the authors clearly differentiate between fundamental aspects of their design as opposed to artifacts of their implementation (that might not exist on another implementation of their design)?

·                                In your opinion, will the solution work as the authors indicated?  Is it applicable in the general case or is it very specific to the cases they used in their evaluation?

·                                What questions does the paper leave unanswered?  Is there future work or is the problem essentially solved by their solution?  What improvements or additional information might you expect from the authors?  Remember that researchers frequently construct prototypes, not products, so improvements should answer important questions, not be requests for functionality that is incomplete, but would be straightforward to add.

Course Project

Students should work in groups of two or individually to do a research oriented course project.  The project will either propose a solution to a security problem, or explore some aspect of computer security.  The project will have three deliverables:

1.                 Project Proposal

Students will hand in a project proposal in the second class.  The proposal should be no more than 2 pages long and should:

  • Introduce and motivate the problem they are going to attempt to solve or what previously unanswered question they are going to try and answer.
  • Give an outline of the proposed solution.
  • Provide a list of related work and an explanation of how the advantage they believe their proposal will have over existing solutions

The instructor will meet with students as necessary to discuss their proposals.  The proposals will then be made available to other students the class via this webpage.

2.                 Project Midterm Update and Presentation

Approximately midway through the course, students will also provide a written report no longer than 3 pages to the instructor summarizing their progress so far.  A class will be set aside for groups to make an oral presentations to the class explaining their project and progress made up to that point.  They will highlight interesting problems they have had and outline their plans for the remainder of the semester.  The class should comment on the project and try to give advice.  For advice on giving presentations, refer here

3.                 Project Research Paper and Presentation

Students will hand in a research paper describing their project.  The paper will be no longer than 12 pages.  The most important goal of any research paper is to confer knowledge that the author learned by doing the research onto the reader.  Thus, when writing the project research paper, students should focus on things they learned in the course of the project, that was not obvious to them before they embarked on the work.  A good research paper should:

·                                Introduce and motivate the problem the paper attempts to solve.

·                                Provide a description of the proposed solution, as well as any interesting implementation details of the prototype (if one was built)

·                                Give a critical analysis of the strengths, weaknesses and limitations of their system, making sure to differentiate fundamental limitations of the solution from limitations specific to the prototype implementation

·                                Conclude with no more than 3 points describing the enlightening things that were learned from doing the research.

For more guidance, refer to information on writing research papers in the Course Resources Section.


Students will also do a presentation for the class summarizing the points of their research paper.  Such a presentation should be clear and concise.  Students are encouraged to use visual aids if the students desire.

Potential Projects

Below are some potential projects, but students are encouraged to up with their own as well!


1.      Combating Phishing Websites:  Phishing websites are websites that fool users into thinking they are a popular website (like a bank) so that they can harvest user information (like username/password).  This project tries to leverage Google as a reputation system to combat phishing websites.  The approach will be to construct a browser plug-in that will scrape a website of unknown repute for keywords, make a query Google with those words, and then compare the URL of the top hit with the URL of the current website.

2.      Automatic Test-generation for Security Vulnerabilities: Recent projects have shown that automatic test generation works for software as well.  See CUTE and EXE.  However, when inundated with bug reports, developers usually want to know which bugs are more important.  Since we feel (and most people agree) that security bugs are the most critical, the goal is to develop a test-generator that will try paths that are more likely to have security vulnerabilities first.

3.      Testing the Less-Common-Path Hypothesis: Conventional security wisdom suggests that code vulnerabilities occur on less commonly executed paths.  We will try to verify that hypothesis in this project.  Students will instrument programs with documented vulnerabilities to gather path-frequency information.  They will then try to determine a statistical correlation between the frequency of paths executed and location of the vulnerabilities.  For an idea on how to profile paths, students are encouraged to look at this paper.

4.      Proxos Development: Code for our system for protecting applications against compromised operating systems, called Proxos, will be made available to the students.  Students may pick from a variety of projects to build on top of Proxos.  The project will involve low-level kernel or virtual machine monitor hacking.  Please speak to the instructor for more information.

Class Project Groups and Proposals

Title of Project and Proposal

Group Members

Midterm Update

Project Proposal: Secure Isolated Copy-on-Write File System

Fareha Shafique


Combating Phishing Websites

Ivan Hernandez, John Leggio


Phishing Detection and Plugin Proposal1 Proposal2

Robert Ma, Dmitry Denisenko


Securing Data in the Event of Computer Theft

Renee Warriner


Correlating Multi-Session Attacks via Replay

Vladan Djeric


Detecting Buffer Overflows by Model-Checking

Kelvin Ku


Smart Cookies: The Unstealable Authentication Cookie

Andrew Miklas, Shvetank Jain


Patagonix: Dynamically Neutralizing Malware with a Hypervisor

Andrés Lagar-Cavilla, Lionel Litty


A Client­Side Browser­Integrated Solution for Detecting and Preventing Cross Site Scripting (XSS) Attacks

Gordon Chiu, Bernice Chan


Correlating Path Frequency with Vulnerabilities

Rita Chiu, Jacky Mok and Vicky Tsang


Worm detection and eradication in Blue tooth Environments

Kiran Gollu



Course Resources

·                                            Lectures:

  1. Basic Concepts and Intro to Cryptography
  2. Exploits : Tutorial on format strings.
  3. Designing and Writing Secure Code
  4. Containment
  5. Browser Security
  6. Operating System Security
  7. Intrusion Detection
  8. Network Security

·                                            Advice on writing papers:

1.      How (and How Not) to Write a Good Systems Paper

2.      Eurosys 2006 Authoring Workshop

3.      Writing Systems and Networking Articles

·         Advice on Presentations from:

  1. Frank Kschischang
  2. Compton & Chang
  3. David Patterson/Mark Hill

Course Schedule



Readings (To be read by this date)


Project Deadlines







2 09/19

The Bad Guys

Smashing The Stack For Fun And Profit. Aleph One.

A note on the confinement problem. Butler Lampson.

Computer Virus-Antivirus Coevolution.  Carey Nachenberg. 





Detecting Exploits

StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks.  Crispin Cowan, Calton Pu, Dave Maier, Heather Hinton, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, and Qian Zhang. 

Dynamic Taint Analysis: Automatic Detection, Analysis, and Signature Generation of Exploit Attacks on Commodity Software. James Newsome and Dawn Song

N-Variant Systems: A Secretless Framework for Security through Diversity. Benjamin Cox, David Evans, Adrian Filipi, Jonathan Rowanhill, Wei Hu, Jack Davidson, John Knight, Anh Nguyen-Tuong, and Jason Hiser.

Jacky Mok, Rita Chiu


Project Proposal



Writing Correct Code

Model checking one million lines of C code. Hao Chen, Drew Dean, and David Wagner.

Using Programmer-Written Compiler Extensions to Catch Security Holes. Ken Ashcraft, Dawson Engler.

Automatically generating malicious disks using symbolic execution. Junfeng Yang, Can Sar, Paul Twohey, Cristian Cadar, and Dawson Engler.

Kelvin Ku, Andrew Miklas, Vicky Tsang

Slides: Mops, MC, EXE





Secure Execution Via Program Shepherding.  Vladimir Kiriansky, Derek Bruening, Saman Amarasinghe

Isolated Program Execution: An Application Transparent Approach for Executing Untrusted Programs.  Z. Liang, V.N. Venkatakrishnan and R. Sekar

Privtrans: Automatically Partitioning Programs for Privilege Separation.  David Brumley and Dawn Song

Fareha Shafique, Bernice Chan, Renee Warriner

Slides: Program Shepherding, Alcatraz




Web Security

A Crawler-based Study of Spyware on the Web.  Alexander Moshchuk, Tanya Bragin, Steven D. Gribble, and Henry M. Levy.

Stronger Password Authentication Using Browser Extensions.  Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell.

A Safety-Oriented Platform for Web Applications.  Richard S. Cox, Jacob Gorm Hansen, Steven D. Gribble, and Henry M. Levy.

Shvetank Jain, John Leggio, Kiran Gollu

Slides: Spyware, PwdHash, Tahoma

Project Midterm update



Midterm Oral Presentations






Operating System Security

Detecting past and present intrusions through vulnerability-specific predicates. Ashlesha Joshi, Samuel T. King, George W. Dunlap, Peter M. Chen.

Terra: A Virtual Machine-Based Platform for Trusted Computing.  Tal Garfinkel, Ben Pfaff, Jim Chow, Mendel Rosenblum, Dan Boneh.

Labels and Event Processes in the Asbestos Operating System.  Petros Efstathopoulos, Maxwell Krohn, Steve VanDeBogart, Cliff Frey, David Ziegler, Eddie Kohler, David Mazieres, Frans Kaashoek, and Robert Morris

Robert Ma, Lionel Litty Slides




Class cancelled






Intrusion Detection and Viruses

Intrusion Detection via Static Analysis.  David Wagner and Drew Dean

A Sense of Self for Unix Processes.  S. Forrest, S. A. Hofmeyr, A. Somayaji, and T. A. Longstaff

Semantics-Aware Malware Detection.  Mihai Christodorescu, Somesh Jha, Sanjit Seshia, Dawn Song, Randal E. Bryant

Vladan Djeric, Dmitri Denisenko, Gordon Chiu




Network Security

Automated Worm Fingerprinting.  Sumeet Singh, Cristian Estan, George Varghese and Stefan Savage

SPV: Secure Path Vector Routing for Securing BGP.  Yih-Chun Hu, Adrian Perrig and Marvin Sirbu.

Vigilante: End-to-End Containment of Internet Worms.  Manuel Costa, Jon Crowcroft, Miguel Castro, Antony Rowstron, Lidong Zhou, Lintao Zhang, Paul Barham

Andres Lagar Cavilla, Ivan Hernandez




Wrap up



Project Final Presentations