There are 3 project options available to 508 students this semester. Students in 408 must do Option 2. You are encouraged to work in groups of 3. No larger group is allowed, unless you're doing a very ambitious project. Groups of 2 are ok. Solo projects are discouraged. Any project work that is to be simultaneously counted towards another class must be approved by me and the other professor.
All projects should culminate in a written report describing your methodology and results. Reports should be 10-16 pages long. Aim high! Any one of the projects described below could result in a publication if done well.
All projects must also have a final meeting with me near the end of the semester. At this meeting, you should describe your methodolgy and results, and I will provide any last-minute feedback on preparing your final report.
Timeline:
| Date | Item |
|---|---|
| Dec. 14-15 | Demos (about 20 minutes) |
| Dec. 16 | Final Report |
Many websites use SSL to encrypt user logons, but then switch back to non-SSL connections for the rest of the user's session. This is surprising because the main overhead of establishing an SSL connection occurs during the initial connection setup. Using SSL afterwards is relatively cheap. Only high-security sites, such as banks, use SSL full-time. Google has discussed enabling SSL full-time for GMail and other Google apps.
In this project, you will perform a detailed performance analysis of SSL-enabled web services to determine exactly what drawbacks there are, if any, to enabling SSL full time. You should set up an SSL-enabled web server and measure its performance along several dimensions, with and without SSL:
Keep in mind that the performance impact of SSL is pretty low, so you will need to set up careful experiments capable of measuring latencies on the order of 1/10th of a second. Also, you should ensure that your SSL server is properly configured -- poor performance on a poorly-configured server is not interesting. For example, your server should support SSL connection caching, HTTP keep-alives, and persistant caching. See this blog entry for a discussion of several SSL performance tips.
If you discover that SSL servers are not well-tuned by default, then you should document the ways the developers can change their defaults to improve performance.
You should also identify any steps in the SSL protocol that are performance bottlenecks.
In summary, your final report should contain
WEP has been broken for years. You can download free WEP crackers from hundreds of websites -- one may even come with your operating system. But where's the fun in that? In this project, you'll write your own attack.
Implementing a WEP cracker involves two steps:
For the data collection phase, you can refer to existing wep cracking tools. You particularly might want to refer to aircrack-ng.
You must implement the cryptanalytic portion of the attack from scratch. This page begins with an excellent summary of the history of attacks on WEP, with links to the relevant papers. Students in 408 do not have to implement the most state-of-the-art attack (the so-called PTW attack). Students in 508 must implement the PTW attack.
Extra credit will naturally be given to anyone who creates a new attack that requires even fewer packets than the PTW attack.
If you find that implementing the data collection phase is too difficult, you can simply use airodump-ng to collect the packets and write your own separate analysis program.
Scoring is as follows
| Phase | Points |
|---|---|
| Collection | 20 |
| Cryptanalysis | 80 |
| New Attack Bonus -- 50% reduction | +25 |
| New Attack Bonus -- 90% reduction | +50 |
Since the cryptanalytic portion of the attack is more heavily weighted, I recommend working on it first. Also, you obviously should not copy any code from the free WEP cracking tools. There aren't that many, and I will check your code against them to make sure that your project is original.
Privacy invasions through blogs and social networking sites have become quite common. Job applicants may not be hired because of photos or blog entries that a potential employer discovers through a google search; students may face disciplanary action for activities unrelated to their school or schoolwork; stalkers and predators may seek out victims through their on-line persona.
Almost all privacy invasions begin with Google, so this project will investigate possible ways for a blogger or social network user to prevent certain people from finding their page via Google. Note that a user of this system may not want her blog to be found by some googlers (e.g. potential employers) but would like to be found by other googlers (e.g. people from her home town).
To begin, you should identify several common classes of google searchers, e.g. potential employers, online friends, real-life friends, family members, etc. For each class, you should identify several pieces of information that class would likely know about their target. For example, a potential employer would likely know his target's educational background, whereas an online friend is much less likely to know that information. Other pieces of information you could consider are: real name, online identities, home town, current town, college or high school, hobbies, current job, names or IDs of friends, etc. Brainstorm to come up with others.
The goal is now to predict whether a member of a given class can find a given blog or social network site using Google. In other words, your system should attempt to answer questions like, "Could an employer (or potential employer) find my blog?"
For this part of the project, you must analyze the content of the user's blog or social networking profile and apply a model of google to determine whether a feasible google search result would contain the user's page. In this particular project, you should focus on FaceBook, since FaceBook profiles contain a great deal of personal information categorized by type (e.g. College, Location, Age, etc). Some of this data can be marked private, and your analysis should keep that in mind.
You must also develop a model of Google searches. What pieces of information are most likely to help a search find the user's profile? How many pages of results do searchers usually click through before giving up? (Note that well-known statistics show that users rarely look past the first 2-3 pages, but it is not clear whether that is because they have already found what they were looking for or because they give up).
For each class of searcher, given the public information on the user's FaceBook profile, how likely is a member of the given searcher class to find the user's blog? This will require a statistical analysis of Google's search results. For example, you could try searching for your own FaceBook page using different pieces of personal information. You may find that some information is more useful than others. You could also try finding a small smaple of FaceBook pages with lots of publicly-viewable personal information. You could then perform Google searchers for each page and for each possible set of search terms. From these results, you can build a model of how likely a searcher is to find the user's FaceBook page given the information they possess.
You should write a report describing the searcher classes you created, your rationale for each class, the information each class would have available to it, your methodology for building a model of Google search results, and the results of your model-building process. Finally, you should test your model against several real-world FaceBook profiles that were not in your training set and report how accurate your model is.