2024/9/24 20:38 Advanced Secure Protocol Design, Implementation and Review
Advanced Secure Protocol Design, Implementation and Review
Start Assignment
Due 18 Oct by 23:29
Points 30
Submitting a file upload
This Advanced Secure Programming assignment is designed to help students apply the theoretical concepts covered in
the lectures/RangeForce and learn about practice secure programming. This assignment is a group work
assignment. In groups of 2-4 students, you will engage in a hands-on assignment that requires the design,
development, and evaluation of a secure overlay chat system utilising a standardised protocol created by all the
students in this class. This system must adhere to class-specified protocol, have a secure implementation, have the
secured implementation intentionally and ethically "backdoored", and then be tested in a controlled code review
process. The course concludes with a friendly hackathon exercise.
Assignment Objectives
Conceptualising and standardising a secure communication protocol for a distributed overlay multi-party chat
system.
There cannot be any central server handling all the communication. Rather, the system must be robust to any node
or device failure.
Develop an application that adheres to a designed protocol (by the class) and incorporates advanced secure coding
practices.
Intentionally backdoor your own implementation in an ethical way so that other groups have security flaws to find.
Perform peer reviews and engage in both manual and automated code analysis to identify vulnerabilities and
backdoors.
Critically reflect on the design and implementation process, including evaluating the protocol, the security measures
implemented, the quality of the feedback received, a reflection on your own learning and possible coding mistakes.
Have fun at an ethical hackathon to identify and exploit vulnerabilities in a controlled setting, enhancing your
understanding of real-world cybersecurity challenges.
Assignment Timeline and Deliverables
Week 2: Complete the initial design of the chat system's communication protocol.
Week 4: Collaborative standardisation of the protocol with class-wide consensus.
Week 6: Finalise detailed plans for code design and start your implementation.
Week 8: Present a functional prototype in the tutorial for initial testing and feedback. Consider this as the deadline to
finish your implementation.
Week 9: Submit the final version of the chat system for peer review. HARD DEADLINE: Wed, 02 Oct 2024. Late
submission policy applies!
Week 10: Conduct code reviews of three other groups' projects using both manual and automated code review
techniques. Provide constructive feedback on the vulnerabilities found in peer reviews. DEADLINE for peer feedback:
Friday, 11 Oct 2024. Late submission policy applies!
Week 11: Submit a reflective commentary discussing the protocol standards, implementation challenges, thoughts on
the embedded backdoors, and their detection difficulty. Include in your submission the backdoor free, and your
backdoored code. DEADLINE: 18 Oct 2024. Late submission policy applies!
Week 12: Participate in a friendly, ethical hackathon to test all chat systems for vulnerabilities and demonstrate proof of
concept attacks in a VM environment.
Participate in workshops to aid protocol development and refine implementation strategies.
https://myuni.adelaide.edu.au/courses/95573/assignments/397468 1/8
2024/9/24 20:38 Advanced Secure Protocol Design, Implementation and Review
Programming and Implementation Details
Your group is free to use any programming language it feels comfortable with, such as C, Python, Rust, or any other
suitable programming language.
Task Overview
The goal is to create a system that functions according to specified requirements and incorporates intentional
vulnerabilities (backdoors) that peers will attempt to identify and exploit. Your aim is to understand the trade-offs in
protocol design at different levels with different objectives and problems. This develops critical thinking about aspects of
protocols, programming, security, and vulnerabilities in code.
In order to achieve that, we will design and secure our own protocol (as a whole class group). We will study this using
the example of an overlay multi-party chat program. At the end of the module, we will have discussed and implemented
a set of major Internet protocols, and you will have a program that must interwork with other students' programs to
provide a chat service with:
Listing all members (currently online) in the chat system.
Private messages to a single participant: For example, your protocol is able to "forward" chat messages to the
appropriate destination (according to your "routing table"), and the appropriate recipient displays the right chat
messages.
Group messages to all participants.
Point-to-point file transfer.
What you need to consider is:
How to secure the socket from which you are receiving data.
Consider a malicious user using your program.
Consider malicious nodes participating in your protocol and/or a malicious actor "wiretapping" your communication.
While at the same time forwarding/routing messages through an overlay topology and securing the protocol
communication.
Consider core functionalities like user registration, and message sending/receiving (/w authentication).
During the workshop session, you will design a protocol where you (the cohort of students) can work together to agree
on a protocol that will be implemented within the chat program. You will then work in small groups (2-4 students) to
implement the protocol independently of the other groups.
Phase 1: Protocol Design (Weeks 1-4)
Objective: Design a standardised network protocol for a chat system that supports listing members, sending private
and group messages, and conducting file transfers—a protocol specification document detailing all functional and
security aspects agreed upon by all groups.
Approach:
Weeks 1-2: Research existing secure communication protocols to understand foundational concepts. Begin drafting
protocol specifications focusing on user authentication, data integrity, and encryption methods. Use the workshop during
week 2 to communicate with your fellow students.
Weeks 3-4: Standardise the protocol in collaboration with your peers in the whole class. Ensure it includes details on
message formatting, session management, packet routing, error handling, and security measures.
https://myuni.adelaide.edu.au/courses/95573/assignments/397468 2/8
2024/9/24 20:38 Advanced Secure Protocol Design, Implementation and Review
Phase 2: Software Implementation (Weeks 5-9)
Objective: Implement the agreed protocol that has been "standardised". Note carefully that while the protocol
specification needs to be the same for the whole class (otherwise, you will not be able to communicate with the
implementation from other groups), your implementation is group-specific. A working prototype of the chat system
should be submitted by every group at the end.
Approach:
Weeks 5-6: Design the software architecture and start implementing it. While you are still in the process of focusing on
completing the last RangeForce modules, it is essential that by the workshop in week 6, you have a clear understanding
of what to code. You should use the session with your tutor to discuss any questions you might have.
Weeks 7-8: These will be the main coding weeks. If you have a well-planned and standardised protocol, you will see
that the actual implementation is not that hard. By the end of week 8, your code should really be finished. See this as
the deadline, so you have a few days to debug your code with other groups.
Tutorial in Week 8: Present a working prototype for initial testing and informal feedback from other groups and tutors.
Week 9: Finish debugging your code and add some backdoors (and/or vulnerabilities only known to your group) to the
code. There must be at least 2 intentional vulnerabilities for the other groups to find. Your friendly hackathon
competition is to make it as hard for the other groups to find those hidden vulnerabilities. However, also keep in mind
that ideally, you need to be able to exploit your own vulnerabilities and demonstrate later that you can achieve the
objectives.
A hopefully obvious but important note on the intentional backdoors: The objectives are limited to within the chat
system. Do not include anything that would breach anything from the computer of the person who runs your code. The
idea is proof of concept, e.g., that you could take control of the running program, modify or alter messages on the node,
sign with their private key, etc. However, keep it ethical. Do not breach anyone's privacy or modify or delete any of the
data outside of this assignment.
On Wednesday in week 9, 02 Oct 2024: Submit your complete chat system (the version of your code with
backdoors/vulnerabilities) for review by other groups. Submit on the MyUni assignment page: Submission of
Implementation (https://myuni.adelaide.edu.au/courses/95573/assignments/397475) . Your submission should have your
(intentionally vulnerable) code and a detailed "README" (as ASCII) with instructions on compiling, running and using
the code.
Phase 3: Testing and Peer Review (Weeks 10)
Objective: Conduct thorough testing and review of the chat system to identify planted and potential unintended
vulnerabilities. Please submit a feedback review report outlining the vulnerabilities found and suggestions for
improvement for the other groups.
Approach:
Week 10: Each student gets 3 implementations from other groups to review. This is an individual sub-task in order to
practice reviewing for every student and maximise the feedback others receive. You will use a combination of manual
inspection and automated tools (e.g., static code analysis/dynamic analysis). Focus on identifying the intentional
backdoors and any other security flaws left by other groups. However, it also provides detailed feedback to other
groups, highlighting both strengths and vulnerabilities in their implementations. Your feedback is expected to be
returned to the other students no later than Friday, 11 October 2024.
Note that you can, of course, share the feedback from the individual peer review task with your group members and
overall make your code better as a group. Feedback given will also discussed in the reflective commentary as a group.
While every group's backdoored code version is implemented ethically, always treat the code or produced binaries as if
they were malicious. The code will certainly open ports to receive messages and will have intentional and/or
https://myuni.adelaide.edu.au/courses/95573/assignments/397468 3/8
2024/9/24 20:38 Advanced Secure Protocol Design, Implementation and Review
unintentional vulnerabilities associated with it. Run code received from other groups only in a sandboxed and
secured environment! It is essential to practice protecting yourself from malware and learning how to become a
malware researcher, as the code you receive should only contain ethical backdoors, but nevertheless, make sure your
own systems remain safe.
Phase 4: Reflection and Feedback (Week 11)
Objective: Reflect on the development process and learn from the feedback received.
Approach:
Write a reflective commentary discussing your protocol's standards, implementation challenges, thoughts on the
integrated backdoors, and anticipated difficulty detecting them. As guidance, do not write more than 2000 words (~4
pages single-spaced A4). Your code, proof of concept, and screenshots can go to a set of appendices, which do not
count into those 2000 words/4 pages.
The reflective commentary should contain the following information:
1. Your reflection on the standardised protocol. Even if you had to comply with the agreed implementation (in order to
achieve interoperability), you might have had a different view. Here is the space to comment and give your thoughts
on what worked and what didn't work.
2. Describe and submit your backdoor free version of the code. Explain design choices in the implementation.
Demonstrate how your code runs (by chatting with your own implementation or by chatting with other
implementations). Discuss lessons learned. This can also include any bugs reported by other groups.
3. Explain what backdoors/vulnerabilities you added. What your thoughts and objectives were. Explain and
demonstrate how to exploit your backdoor.
4. Evaluate the feedback you received from other groups. Did they find your backdoors? Did they find other problems
in your code? Was the report useful feedback?
5. For what groups did you provide feedback (name the group and group members). What feedback did you provide to
other groups? What challenges did you face? How did you overcome or approach those challenges (e.g., did you
talk to the other groups)?
Phase 5: Ethical Hackathon (Week 12)
Objective: Test the security of all chat systems in a controlled, ethical environment.
Approach:
Participate in a hackathon where each group attempts to exploit vulnerabilities in others' systems. That means running
your own vulnerable code in a VM (or otherwise safe environment). Ethically, try to exploit others' code. Use only non-
destructive methods and aim to demonstrate proof of concept for potential attacks. All activities should be conducted on
isolated virtual machines (VMs) to prevent any real-world implications.
Secure Programming Assignment
https://myuni.adelaide.edu.au/courses/95573/assignments/397468 4/8
2024/9/24 20:38 Advanced Secure Protocol Design, Implementation and Review
Criteria Ratings Pts
Reflective
1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
commentary (not
Critical reflection Reflection Thoughtful action Non-reflective
including appendices)
Exploration and critique Movement beyond or introspection Superficial
– Writing spectrum
(including self-critique) of reporting or descriptive Elaborated descriptive writing
assumptions, values, writing to reflecting (i.e. descriptive writing approach (fact
beliefs, and/or biases and attempting to approach and reporting, vague
1.5 pts
the consequences of understand, question, impressions impressions)
action (present and future). or analyse the learning without deeper without reflection
Including but not limited to related to secure reflection. or introspection.
the ones learned in the programming).
course.
Reflective
1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
commentary – Clarity
Reflective practitioner Aware Reflective novice Language is
The language is clear and practitioner There are frequent unclear and
expressive. The reader can Minor, infrequent lapses in clarity confusing
create a mental picture of the lapses in clarity and/or accuracy. throughout
1.5 pts
situation being described. and accuracy. Concepts are either
Abstract concepts are explained not discussed or
accurately, making sense to an are presented
uninformed reader. inaccurately, or are
too vague.
Reflective
1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
commentary –
Bigger picture clearly Ability to analyse Some Irrelevant
Relevance
communicated biases, demonstrated Most of the
The reflection demonstrates stereotypes, and relevance reflection is
the ability of the student to preconceptions Attempts are made irrelevant and/or
question their own biases, The reflection to demonstrate misses the
stereotypes, preconceptions, demonstrates the relevance, but the bigger picture of
and/or assumptions and define student's ability to relevance is unclear understanding of
new modes of thinking as a question their to the reader or not the topic area.
result of the perspective of the biases, stereotypes, linked to the bigger 1.5 pts
cyber security skill shortage and picture of the cyber
and secure programming preconceptions. security market
culture in the world. This could needs and/or secure
also reflect on your own programming.
engagement with respect how
your high quality posts on
Piazza changed the learning
for other students, for
example.
Reflective
1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
commentary –
Critical reflection Connections Little to no attempt to No attempt to
Course/curriculum
The reflection demonstrated demonstrate demonstrate
context
demonstrates an The reflection connections connections
understanding of the demonstrates There is little to no No attempt to
experience in relation to connections between attempt to demonstrate demonstrate
1.5 pts
material from other the experience and connections between connections to
courses, past experience, material from other the learning experience previous learning
personal goals, and/or courses, past and previous other or experience.
the wider cybersecurity experience, and/or personal and/or
skill sets. personal goals. learning experiences.
https://myuni.adelaide.edu.au/courses/95573/assignments/397468 5/8
2024/9/24 20:38 Advanced Secure Protocol Design, Implementation and Review
Criteria Ratings Pts
Reflective
1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
commentary – Use of
Critical reflection Good Adequate Superficial
AI
The reflection on the use of The reflection on the The reflection on the The reflection is
AI is comprehensive. The use of AI is thorough. use of AI is clear. The superficial and
main reflective report The main reflective main reflective report shows a limited
provides a detailed account report describes how explains how AI was understanding of
of how AI was utilised in the AI was utilised in the used in the AI capabilities
assignment and what assignment, assignment, and constraints.
strengths or weaknesses specifying tasks and mentioning specific Or the report
were identified. The report results. The tasks and outcomes. does not detail
also critically evaluates AI's reflection evaluates It details some whether and how 1.5 pts
limitations and AI's limitations and limitations and AI was used.
shortcomings and includes shortcomings, shortcomings of AI,
thoughtful insights into what showing a good showing an adequate
the group learned from understanding of its understanding of its
using AI. Or if AI was not capabilities and capabilities and
used at all in no way, the limitations. constraints.
report states that this
assignment was conducted
without the help of AI.
Reflective
1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
commentary –
Detailed Basic List Not present
Contributions of
The report reflects on There is a section present in There is just a There is no
group members (at
what every member the main part of the list with reflection on the
the end of the main
contributed to the group reflective commentary. Still, percentages of group’s
reflective
and how the group it lacks details or clarity each team contributions or
commentary section)
worked on this (e.g., it might just give the member. percentages of
1.5 pts
assignment. This percentages of group group members'
includes percentages of members but does not overall
each group member's reflect on strengths or contribution to the
contribution to the weaknesses and how the assignment.
overall assignment. group complemented each
other in the learning
experience).
Protocol Design -
1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts
Reflection (protocol
Critical reflection Deeper Thoughtful action Non-reflective
description in
Reflection and critique understanding or introspection Describes the protocol
appendix, reflection
of own contribution to Reflects on the Provides a detailed design superficially
in main part)
the protocol design, reasoning behind description of the without reflection on its
including assumptions, design choices, protocol design effectiveness,
design decisions, and demonstrates a clear process (in the shortcomings/flaws or 1.5 pts
consequences. Also understanding of the appendix) but lacks alignment with course
discusses how their technical details, and a deeper reflection concepts.
own ideas may have how they contribute to on its implications
differed from the class- the consequences of and effectiveness.
chosen protocol. the protocol.
Implementation (code 1.5 to >1.0 Pts 1 to >0.5 Pts 0.5 to >0.0 Pts 0 Pts 1.5 pts
in GitHub) - README
Good README Vague README README lacks Essential
Student names and group Student names, important information
names are present in all group names, and information missing
files (README and all code README are Student names, Student names,
files). The README shows present, but the group names, and group names, or the
https://myuni.adelaide.edu.au/courses/95573/assignments/397468 6/8
2024/9/24 20:38 Advanced Secure Protocol Design, Implementation and Review
Criteria Ratings Pts
a command-line example of instructions for README are README file are
how to run the program, installing and/or present, but they missing. The
lists all dependencies, and running the code lack an example of vulnerable and non-
gives guidance on how to are vague. how to install or run vulnerable versions
install the code. the code. of the code are not
clearly identified.
Implementation (code
4 to >2.5 Pts 2.5 to >1.0 Pts 1 to >0.0 Pts 0 Pts
in GitHub, detailed
Testing methods well Testing methods Testing methods Testing method
tests documented in
described adequately described lack thoroughness not structured
GitHub files or
Details a testing method The report reflects on A systemic and or not
appendix, reflection
(in the main document) testing for structured testing adequately
on testing described
and has a detailed test interoperability with method is described described
in main part) –
plan (in appendix or other groups. Still, it but does not mention Testing
Testing and
GitHub file). Names with does not give full interoperability tests methodology 4 pts
Interoperability
what other groups' details on the testing with other groups in missing from the
interoperability has been procedure or lacks the main part of the main part of the
tested describes how the details on what other reflective reflective
tests were conducted, and groups and what has commentary section. commentary or
results. Testing has been been learned from the lacks evidence for
done with the code of at testing. a systematic
least 5 other groups. testing approach.
Implementation (code
4 to >2.5 Pts 2.5 to >1.0 Pts 1 to >0.0 Pts 0 Pts
in GitHub) – Code
Outstanding Good Adequate Poor
Quality
Code works out of Code has some The code is functional in the Code lacks
the box, has good weaknesses (e.g., use cases described in the essential
error handling, and not all corner cases README. The basics are elements, does
deals well with failure produce clear error correct, e.g., not implement
4 pts
scenarios (e.g., messages or good routing/forwarding tables some aspects of
network nodes are handling). are correct, and messages the protocol,
not gracefully shut in the overlay do not loop. and/or does not
down). implement the
standard correctly.
Feedback given 4 to >2.5 Pts 2.5 to >1.0 Pts 1 to >0.0 Pts 0 Pts 4 pts
(evidenced in the
Exemplary Accomplished Intermediate Novice
appendix)
The feedback The feedback The feedback offers a The feedback provides
presents clear, provides a clear and basic explanation of a limited or unclear
cohesive helpful explanation of how to improve the explanation of how to
explanations of how how to improve the code. The writing is improve the code. The
to improve the code code. The writing is generally constructive writing lacks
(of the other groups). constructive and and supportive but constructiveness,
The writing is supportive but might may lack clarity or offering minimal help
constructive, be vague in parts, or detail. The feedback for the other group to
supportive, friendly, the testing provides some useful learn or improve their
clear and detailed methodology of the insights but misses code. The methods to
enough to help the other group's code some key areas for test the other group's
other groups learn lacks rigour. The tests improvement. The code are basic and
from the feedback conducted are limited methods to test the show a limited
and improve their in their methodology, other group's code understanding of
code. The methods to and the feedback primarily rely on secure programming.
test the other group's does not fully techniques learned in
code go beyond the demonstrate that all the class and
methods learned in aspects of the code demonstrate an
this class and have been thoroughly adequate
demonstrate a strong reviewed.
https://myuni.adelaide.edu.au/courses/95573/assignments/397468 7/8
2024/9/24 20:38 Advanced Secure Protocol Design, Implementation and Review
Criteria Ratings Pts
understanding of understanding of
cyber security. cyber security.
Ethical
6 to >4.0 Pts 4 to >2.0 Pts 2 to >0.0 Pts 0 Pts
backdoor/vulnerability
Outstanding Good Adequate Superficial
(described in the
The ideas behind the The ideas behind the The ideas behind the The ideas behind the
main part and
ethical ethical ethical ethical
submitted as
backdoor/vulnerability backdoor/vulnerability backdoor/vulnerability backdoor/vulnerability
quarantined file in
are complex and are well-thought-out and are clear and are basic and
GitHub)
innovative. They demonstrate a solid demonstrate a good demonstrate a limited
demonstrate that the understanding of secure understanding of understanding of
group deeply programming and code secure programming secure programming
understands secure weaknesses. A PoC and code and code
programming, code implementation is weaknesses. A PoC weaknesses. The
weaknesses, and submitted for at least implementation may backdoors in the
exploitation methods. one not be submitted, but vulnerable version of
An appendix or backdoor/vulnerability, the reflective the code offer a
GitHub file details a and the reflective commentary makes it minimal challenge to
Proof of Concept commentary makes it credible that this can other groups. There
(PoC) implementation credible that all be exploited. At least might also be fewer 6 pts
on how the planted backdoors/vulnerabilities 2 backdoors are than 2 backdoors in
backdoors can be can be exploited. At present in the the code.
exploited. For at least least 2 backdoors are vulnerable version of
2 backdoors, there is present in the vulnerable the code, providing a
evidence that the version of the code, moderate challenge
group can exploit challenging other groups to other groups.
their own backdoor. to identify and
More than 3 understand different
backdoors of varying types of vulnerabilities.
complexity are
present in the
vulnerable version of
the code, and at least
one provides a
significant challenge
to be identified.
Total points: 30
https://myuni.adelaide.edu.au/courses/95573/assignments/397468 8/8
