Instructor: Professor Atul Prakash
EECS 588
Fall 2007
Credits:
4. (This course qualifies
towards meeting software quals requirements)
Prerequisites: EECS 482 or EECS 489 or grad standing.
Understanding projects and papers well is likely to require some
Operating Systems or networking background as an undergraduate or
graduate student.
Schedule: Lectures: TuTh 1:30-3:00, Friday, 1:30-2:30,
3150 Dow.
Office Hours: 3:00-4:00 TuTh, 4741 CSE.
This course will discuss foundational work and research papers in the following areas: Cryptography background and review of some current topics, including hash functions, public/private key encryption, block ciphers, and Merkle-hash trees; security issues and attack on real-world systems; security models, operating systems security, reverse-turing tests; public key infrastructures and key management issues, and policy management. The course will also have a fair amount of formal material on applicability of Baysian methods to intrusion detection, spam filtering, etc.
Part of the goal of the course is to be comfortable with designing and evaluating security in systems and to prepare for research in the area.
Attack trees. Bruce Schneier's note.
HW 1:
Is your account at DCO or CAEN secure? Define what you mean by that and state some of the key assumptions for it to be considered secure.
Draw an attack tree in which you show how an adversary who does not have access to your account could potentially violate at least one of your assumptions and compromise your account's security. Make sure you explore multiple avenues for the adversary to violate the assumption, since the first line of attack may not work for the attacker. Bring your solution to the class on Friday, Sept. 7th (or email to me). We will discuss a few of the solutions in the class.
Crypto Background -- Tradeoffs among block encryption modes for providing confidentiality
HW2: Due Sept. 25th. Group work allowed.
Crypto Background -- RC4, performance comparison, hashing, HMAC
Side Note: Recent attacks on cryptographic hash algorithms and their ramification
N. Borisov, Ian Goldberg, and D. Wagner. Intercepting Mobile Communications. The Insecurity of 802.11. [pdf]
Read on "Needham-Shroeder symmetric key" and the attack on it at the [list of security protocols]. Also read on Kerberos.
BAN logic overview. We primarily talked about the first item below. The 2nd one adds more depth and discusses the Needham-Shroeder protocol's analysis with BAN logic.
D.X. Song, D. Wagner, and X. Tian. Timing Analysis of Keystrokes and Timing attacks on SSH. [pdf]
This paper makes use of techniques from probability and AI, which are also helpful in understanding papers on intrusion detection and spam filtering. If you have taken an AI course and have its textbook, you may find it useful to look at the material on conditional probability (especially Bayes law) and hidden markov models. If you haven't, don't worry. We will review what we need below.
Measuring information content: Chapter 3 (primarily sections 3.1-3.3) from the following online book by Neal Wagner: [pdf]
Here is a [link] that I found useful in getting an overview of markov models and the use of hidden markov models for pattern recognition.
A reference book is optional for the course. It is good to have one security book around as a general reference. One of these or most others would do.
Cryptography and Network Security. Behrouz Forouzan, McGraw Hill
Stallings, Cryptography and Network Security, Third Edition.
Matt Bishop, Introduction to Computer Security, Addison-Wesley, 2004.
Gollman, Computer Security, Wiley.
In my experience, the best way to learn security topics is to do some hands-on work related to security. So, you will get some hands-on work (homeworks) at various times during the semester, amounting to a 3-4 hours per week of work on the average. This will constitute 36% of the grade. Usually, this can be done in groups of two to three (with relative contribution stated in the submission or emailed to me), unless specified as requiring individual work. These will be generally graded loosely as Check+, Check, or Check-. We will usually discuss a subset of the solutions in the lectures so that the whole class can benefit from different perspectives that students took for solving a problem. (If you do not want your solution discussed in the class, indicate so at the top of your submission.)
We will use part of the Friday time to discuss top vulnerabilities and open source or high quality security tools. One list of tools can be found at http://sectools.org and a list of top targets for vulnerabilities can be found at http://www.sans.org/top20. Each student will prepare a few slides or a demo of one tool and one vulnerability and present once over the course of the semester. You can work in groups to coordinate and discuss, but each person should take the responsibility for giving an overview of one tool and one vulnerability and take about 10 minutes. 9% of the grade. We will start this from 2nd week and I would like 3 students to volunteer each week.
Class Project (including presentation and reports): 50% (can be done in groups appropriate to the size of the project). Students in the class will rate the projects they liked at the end of the class, which will be an informal input into my own grading. Some things I look for:
Why is the project interesting? Is there a research value? Does it fulfill a missing need?
Project presentations: how well were you able to present your ideas to the class? How did class react to your presentation? Did you state the goals and clearly state the results and limitations of your work?
Project demonstration: does it work? Can we see a demo during your presentation? Demos are of course not applicable to all projects.
Paper/report: Is it publishable as a conference paper? Is it likely to be useful to someone? Is it well-written?
Source code or binaries: Is it published and/or usable by others? Is your prjoject likely to be useful to someone?
Planning and execution: Did you make tangible progress throughout the semester? (This is good). Or was it all done in the last few weeks? (Not good). I will judge this based on your interactions with me during office hours or via email, regarding your project. Feel free to keep me informed of your progress or bottlenecks, though there is no formal requirement of intermediate reports.
You can choose your own class project, based on a need you perceive or from a list that I provide. Generally, the best projects have either some good insight and research contribution (i.e., it can potentially lead to a paper) or provide a good implementation to solve a real-world need. You should submit an abstract of the planned project by Sept. 25th and the plan for carrying out the project by Oct. 2nd. The project will be due by Dec. 13th. Presentations will take place from Dec. 1st. So, you should have most of your results by Dec. 1st.
For group work, I will expect a short statement from each partner about their and their partner’s relative contributions to the project. This may be an input to your grade where a partner’s contributions lags significantly.
Class and newsgroup participation: 5%. The average grade here is expected to be 3%. You may get higher if you contribute to the class discussions so that the class benefits. For example, following security forums (Slashdot and bringing attacks or techniques of current interest to the attention of the class is one way to contribute to the class discussion.
Please read information on
Engineering
Honor Code. You are all expected to observe it.
In this
course, you may also learn techniques to compromise security of
systems, since to be a good designer of secure systems, you need to
be familiar with threats. However, using those techniques in real
world may violate law and university's computing practices.
Please read CAEN's
policy document on rights and responsibilities and the links
under that page on guidelines at UM for use of technology resources.
As members of the university, you are expected to adhere to the
policies.