UoB Logo

Home

Projects

Course Staff

Instructor: S. Nagaraja
Email: nagaraja
Phone:
Office: 132, School of Computer Science
Hours: Tuesdays 4-5 pm
Lectures: 22
Location: location information
Credits: 20
Mailing list: mod-net-sec@cs.bham.ac.uk

The newsgroup is for questions/discussion on homeworks and programming assignments. But do not post solutions (code or write-up) to the newsgroup! Use email only when you cannot use the newsgroup, e.g., for urgent/personal questions.

Chris Novakovic
Teaching Assistant
Email:cxn626
Office: see notice on 117
Hours: Mon, Tue: 4pm-6pm

Joe Gardiner
Teaching Assistant
Email:j.gardiner
Office: see notice on UG41
Hours: Wed: 10am-12pm, Thu: 4pm-6pm





Network Security: Team Projects

As part of the Network Security module, you must complete a network security-themed team project. The project is worth 50% of your final mark for the module.

All projects will be jointly supervised by Joe Gardiner and Chris Novakovic.

Groups

The teams consist of either three or four students. The memberships of each team are listed below.

Team 1:
Alaa Hassan
Najwan Hudaihed
Marios Zinonos
Team 5:
Yuchong Cheng
Wen Lu
Zhiyuan Lu
Team 2:
Sittikorn Assavanives
Panpete Jivanantapravat
Kitipong Sritaweesap
Team 6:
Apostolos Giannakidis
Pierre Pavlides
Evgeny Zhavoronkov
Team 3:
Donald Mkpanam
Rajiv Singh
James Walker
Team 7:
Panagiotis Gialouris
Megan Thomas
Thomas Yorkshire
Team 4:
Binbin Hu
Ye Tian
Tzu-Yi Wang
Bo Wu
Team 8:
Said Al-Riyami
Shupeng Hu
Matimbila Lyuba
Wenjiao Zhao
Weekly Meetings

Each team will meet with Joe and Chris once each week to discuss progress. These meetings are compulsory, and you should email both of them (along with the other members of your team, as a matter of courtesy) if you are unable to attend for any reason.

Mondays
(All weeks: room 225)
16:00 – 16:20: Team 3
16:30 – 16:50: Team 7
17:00 – 17:20: Team 1
17:30 – 17:50: Team 6
Wednesdays
(Until February 13: room LG05)
(February 20 – March 6: room 222)
(March 13: room LG05)
(March 20 onwards: room 222)
10:00 – 10:20: Team 8
10:30 – 10:50: Team 2
11:00 – 11:20: Team 4
11:30 – 11:50: Team 5


Your Team's Project

There is an approved list of project ideas that you can use as a basis for your proposed project. Some of these ideas are simplistic, and you will need to extend them with ideas of your own to make them suitable for an 8-week project. Some of the ideas include a bibliography of related previous work; you should read the papers and journal articles in the bibliography if you plan on starting a project in that area.

To obtain a pass mark (i.e., 50%) for the continuous assessment component of this module, your project should meet the following requirements:

  • it must provide channel confidentiality and integrity;
  • it must provide authentication, where appropriate;
  • routing must be performed in a decentralised manner (i.e., there should be no centralised controlling resource).

To improve your chances of scoring higher marks, your team's application/protocol should attempt to provide additional security guarantees. Some suggested security guarantees are listed below; bear in mind that not all of these will be applicable to your project, and that some of them conflict with each other. The value in square brackets is the number of marks your team will be awarded for a perfect provision of that security guarantee.

  • Ordering: guarantees the correct timing/chronological display of messages/packets in the application/protocol. [15%]
  • Unlinkability: prevents attackers from identifying the connection between the sender and recipient of a message/packet in the application/protocol. [10%; up to 20% if resistant to traffic analysis]
  • Non-repudiation: provides proof of the origin/integrity of a message/packet, and prevents the sender from claiming at a later time that the message/packet did not originate from them. [15%]
  • Plausible deniability: allows a user to deny having sent a message to another user at a later time, with an adversary being unable to prove otherwise. [15%]
  • Resistance to external active attacks: guarantees that the application/protocol will still function as intended even if an adversary manages to attack the network infrastructure (e.g., by disabling a node). [15%]
  • Resistance to external passive attacks: guarantees that the application/protocol does not leak information about messages to external entities (e.g., network administrators, keyloggers). [10%]
  • Resistance to misbehaviour: prevents a faulty or malicious node/user from affecting the secure operation of the network. [15%]
  • Unobservability: provides a user/node with access to a resource/information without an adversary learning that the resource/information is being accessed by that user/node. [5%; up to 20% with a covert channel design]
  • Information diffusion: the application/protocol provides redundancy and/or error correction. [10%]

You should not try to provide every possible security guarantee. It is better to provide two or three of them well than five of them inadequately. If you have unused time toward the end of your project schedule, you may of course attempt to provide additional security guarantees.



Mark Rubric

Design + Coding (20%)

Basic: 10%
  • Decentralised routing algorithm (4%)
  • Node joining/departure + user passwords/keys (3%)
  • Channel security design (3%)
    • Key Management
    • Authenticity
    • Integrity
Advanced: (Basic 10% + 10% = 20%)
  • DHT Routing (8%)
  • Internal active attack resistance (10%)
    • Detect four different attacks, percentage split between them
  • External active attack resistance (5%)
    • redundancy
    • Targeted and random dropped nodes
  • ordering (5%)
    • skewed clocks
    • dead nodes
    • network delay
    • ordering attacks
  • Mishehaviour detection (5%)
  • Anonymity (10% for each of the below)
    • Unlinkability
    • Unobservability (use stego)
  • Non-repudiation or repudiation (5%)

Analysis (25%)

Basic:
  • Scalabilty (5%)
    • Simulate large number of nodes (1k)
  • Node dropping (5%)
  • Performance metrics (5%)
    • Delivery rate
    • Delay
Advanced: (10%)
  • Analysis of advanced design features such as scalability upwards of 5-10k among many others
  • Implementation of key logging (5%)
  • Ordering analysis (5%)
  • Misbehaviour analysis (5%)
  • Non-repudiation or repudiation (2%)
  • Malicious node resistance (5%)
  • Internal/external surveillance resistance (5%)
  • Unlinkability analysis (5%)
  • Unobservability analysis (2%)
  • Information diffusion/redundancy analysis (3-10%)


Version Control

So we can accurately assess your progress (and check individual contributions to the project), we require that you commit all relevant work on your team's project to a repository on the School's Subversion server. You must commit work under your own username.

You should use the repository URL

https://codex.cs.bham.ac.uk/svn/netsec/teamN/

where N is your team number in the list at the top of this page.



Deadlines
  • January 23, 2013 at 12 noon: short abstract — your team must have selected a project by this deadline. You need to submit a one-paragraph description of the project you have chosen, along with the extensions your team proposes to investigate, to the School's online submission system.
  • January 28, 2013 at 12 noon: project proposal — this is a document consisting of:
    • an extended abstract describing your team's project in more detail — at a minimum, your team should read the entries in the bibliography for your chosen project; it is also advised that you search for other related papers and journal articles. By this time, your team should have a reasonable understanding of previous work in the research area, and its strengths and weaknesses. The extended abstract should describe the previous work and how you plan on replicating, extending or using it.
    • a project schedule — this should break down the work involved in completing the project, and describe when each piece of work will be completed. Work units should be broken down in such a way that a single work unit should take no longer than three days for one team member to complete (e.g., "writing the code" is too broad; "writing method xyz()" is too detailed).
  • February 26, 2013: project presentations — this is an opportunity to present your chosen research area to your fellow students. It should explain the background to your project and the related work in the area. If your project involves writing code or data collection and you're in a position to demonstrate a prototype of the code or display some of the data you've been able to collect, it will improve the quality of your presentation. The lecturer, teaching assistants and other students will be given the opportunity to ask questions about the research area and your project. The presentation is assessed, and attendance is compulsory.
  • Final week of the semester: project presentations — these will present your team's finished project to the lecturer and teaching assistants, and will be assessed. The format will be similar to the unassessed project presentations.
  • March 22, 2013 at 12 noon: security analysis document — this should discuss the performance, scalability and security properties provided by your project.