CSC8208代做、代写Java/c++编程设计

日期：2024-03-08 11:09

CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024

CSC8208: Module Handbook

Carlton Shepherd and Shishir Nagaraja

{carlton.shepherd,shishir.nagaraja}@ncl.ac.uk

March 1, 2024

1 Introduction

Welcome to CSC8208: Research Methods and Group Project in Security and Resilience! In this module, you

will work as a team to research, design, implement, and evaluate a software system within the context of a

security-related topic. This handbook aims to establish the expectations, module structure, assessment and

marking criteria, and the way in which teams will be chosen and monitored during the course of this module.

In this module, you will gain experience with reading and understanding research papers within the field of

cyber security. In the last 25 years, 3015 papers have been published in the top four security-research conferences. New security knowledge is often first published in scientific papers; the skill for reading, assimilating,

and communicating new knowledge is a crucial one in the long term.

You will work largely independently as a team using your own initiative with minimal supervision. This

is similar to the way in which your individual project (dissertation) supervisor will likely operate. Lectures

are delivered to support the development of your group projects, covering material on reading and writing

papers, evaluation methods, and more. On CSC8208, all course materials and discussions will be hosted and

conducted respectively on Canvas for later reference.

The following academic staff will deliver CSC8208 this academic year:

? Prof. Shishir Nagaraja: Co-module Leader.

? Dr. Carlton Shepherd: Co-module Leader.

2 Module Calendar

During this module, you will go through a series of lectures to help you learn best practices in reading and

presenting research, and writing a report on your findings. You will be organised into groups of approximately

eight members per team. You will then briefly read all papers towards the Assessment 1: Literature Review,

Threat Model & Security Policy. Assessment 1 involves concisely summarising a subset of these research

papers, which should assist you in the final report.

The rest of the module is dedicated for the collaborative Group Project as outlined in Assessment 2: Project

Report. Your project must also be demonstrated. Students are expected to start working on a comprehensive

project that is meticulously executed and documented in a report.

2.1 Lectures

The lectures are scheduled to be delivered in the following order:

1. Module introduction. 10:30–11:30, Monday 12th February 2024.

2. Project briefing. 11:30–12:30, Thursday 15th February 2024.

3. Establishing a common vocabulary on security and resilience. 10:30–11:30, Monday 19th February 2024.

4. Implementation guidance. 11:30–12:30, Thursday 22nd February 2024.

NEWCASTLE UNIVERSITY Last modified: March 1, 2024 1

CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024

5. How to read a research paper. 10:30–11:30, Monday 26th February 2024.

6. Writing and presenting a project. 11:30–12:30, Thursday 29th February 2024.

7. How to evaluate a project (Part 1). 10:30–11:30, Monday 4th March 2024.

8. How to evaluate a project (Part 2). 11:30–12:30, Thursday 7th March 2024.

Location: FDC.G.06.

2.2 Tutorial Sessions

Several tutorial sessions are scheduled in your timetable. It is expected that one member per team, at an

absolute minimum, will attend in order to provide a update on the team’s progress at each session. Team

mechanics are described in greater detail in §4. These sessions take place on:

1. 26th February 2024.

2. 4th March 2024.

3. 11th March 2024 (For the formative assessment of teams 1–11).

4. 18th March 2024 (For the formative assessment of teams 12–22).

Location: USB 1.006 at 13:30–14:30.

2.3 Assessment Deadlines

The following assessments are set, along with their respective weightings:

1. Literature Review, Threat Model and Security Policy (30%): This assessment broken down into:

(a) 20%: Summarise three research papers from the repository provided on Canvas. These focus on

different research directions, such as system security, malware, and Internet of Things security. Each

summary should be ～1,000 words.

(b) 5%: Submit a threat model that you will address specifically in your secure chat project. This includes a concise description of the attackers and attack methods with appropriate justification.

(c) 5%: Submit a security policy comprising a concise set of rules (bullet points) which can serve as the

security requirements that, if met, will successfully protect against the attackers in the threat model.

Your submission must have a maximum length of 5 pages in total using the IEEE Computer Society

double-column conference template. Markers will be under no obligation to mark beyond this: you

may miss out on marks if you exceed this limit.

? Due date: 4th March 2024.

? Submission type: PDF.

2. Presentation (Optional/Formative): A verbal presentation in an elevator pitch style of your developed

project. This should be delivered in person on 11th March 2024 (Teams 1–11) and 18th March 2024

(Teams 12–22). It should be 5 minutes in duration. There is no formal marking scheme.

3. Final Group Report (70%): Presents your developed solution to the project brief. Your report must be

max. 10 pages, again using the IEEE template. Markers will be under no obligation to mark beyond this.

You must also submit a video file that demonstrates a working project.

? Due date: 22nd March 2024.

? Submission type. a PDF (report) and ZIP file containing your software artefact AND a video

demonstration of your project (e.g. MPEG4).

NEWCASTLE UNIVERSITY Last modified: March 1, 2024 2

CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024

All assessments are group-based. Marks are distributed to individuals using the formula described later in

§4.3. Within each assessment, we expect that students submit their contribution percentages within an

appendix chapter.

NESS must be used for submitting your assessments.

3 Project Brief: A Secure Chat System

Secure communication is a major concern for personal and professional use, with numerous solutions having

emerged over the years. The current wave of secure chat clients dates as far back as 2004 with the development

of the Off-the-record (OTR) messaging protocol [1], which supports secure instant messaging with message

encryption, authentication, and forward secrecy. Signal, Theema, Telegram, and WhatsApp represent some of

the most widely used secure messaging solutions in today’s marketplace.

In this project, you are tasked to design, implement, and evaluate a chat system that provides one-to-one

or group-based communication. Your system must allow at least two communicating entities to send and

transmit messages over a secure channel to each other. You have two overarching tasks to complete, which are

described in the following subsections.

3.1 Task 1: Literature Review, Threat Model, and Security Policy

You will begin with a literature survey by selecting and reviewing any three research papers from a predetermined list of scholarly articles provided by the staff. You should briefly read all papers before selecting

and reviewing three papers that you deem most interesting and appropriate from which to develop your final

project (Task 2). Be mindful of a literature review’s purpose: it is not a list of papers described uncritically.

This is the first part of the assessment.

In the second part of the assessment, a threat model and security policy will be devised, pertaining specifically

to your project. The definition of a “secure” chat system is left purposely vague for you to define. Therefore,

you are required to submit a threat model and a security policy aligned with your chosen theme and research

papers. The threat model will concisely state the potential threats and the attacker capabilities that your project

will address. This should be a brief (0.5 page) description. You must also present a basic security policy. This

will be presented as a concise set of rules, i.e. bullet points, which can serve as the security requirements that

if met, will successfully protect against attackers (1 page).

Your group-based paper reviews, threat model, and security policy attracts 30% of the overall module mark.

A breakdown of the marking criteria is given in §5.

3.2 Task 2: Build and Write-up Your System

The design, implementation, and evaluation of your own secure chat system is the main task in this module.

Your system is described in the final report, which must be written in the style of a scientific paper, attracting

70% of the module mark. Broadly, your report should include introducing the problem, providing a related

work section, discussing your design and implementation decisions, how you evaluated your system, and

conclusions with directions for future research. In the report, you will primarily be assessed with respect to

three dimensions: 1 security, 2 resilience, and 3 innovation. The strength of your project’s introduction,

evaluation, and presentation are also assessed.

3.2.1 Dimension 1: Security

This dimension assesses how your system addresses a reasonable threat model and security policy.1 The quality

of the mitigations is of paramount importance. Good projects are expected to use mitigations that follow

current best practices and use existing libraries (e.g. see “don’t roll your own crypto” in §6).

1Your threat model and security policy may be refined from the first assessment for your final project report.

NEWCASTLE UNIVERSITY Last modified: March 1, 2024 3

CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024

For the avoidance of ambiguity, we expect the following to be satisfied as minimum ‘must have’ requirements in

order to achieve a basic pass:

? Confidentiality: Ensure that any transmitted messages between clients cannot be trivially read over a

network medium.

? Integrity/authenticity: Ensure that trivial changes to any transmitted messages can be detected. For

example, if A sends “Let’s meet at 9am tomorrow” to B, then a third party, C, should not be able to change

this to “Let’s meet at 10pm tomorrow” without it being detected.

? User authentication: How will you ensure that only a given user can log into their account? For example,

through the implementation of secret-based methods, e.g. requiring passwords or biometrics to log in.

Beyond this, higher-scoring projects should convincingly provide additional features. As a general guideline, a merit-level project should implement one of the following; a distinction-level project would implement

more than one of:

1. Secure file transfer: In addition to simple messages (strings), can you enable the secure transmission of

files, e.g. PDFs and images, between clients in an efficient way?

2. Message self-destruction/deletion: Can you enable users to delete messages in a way that leaves no trace

of them on their device, server etc.? This could be time-based, e.g. similar to WhatsApp’s time-limited

messages, or on demand from the user.

3. Secure persistent message storage: How could you ensure that messages are stored securely at rest?

This could applied to the user’s device or the chat server.

4. Biometrics: To enhance usability, could you enable users to log in to their accounts using their fingerprint, or facial image etc.?

3.2.2 Dimension 2: Resilience

Implementing resilience into any chat system requires various considerations to ensure reliability and robustness. As a minimum requirement to achieve a pass in this dimension, your project should allow more than

one communication session at a time. Beyond this, it is expected that you explore a wider range of techniques

to protect against unintended faults. A good (merit-level and above) project should implement at least one of

the following aspects:

1. Redundancy and failover: Can you use multiple servers/instances to ensure that, if one server/instance

fails, another can take it over seamlessly?

2. Data backup, replication, and recovery: Does your project regularly backup data and have a recovery

plan in place? The goal would be to quickly restore your service in the event of a major system failure.

3. System monitoring. You may implement substantial alerting mechanisms, for example, to help identify

and remedy faults and other issues as they arise.

4. Scalability. How will your system handle large amounts of traffic, which may hinder the delivery of

legitimate messages (among other problems)? Design mechanisms that gracefully handle this increased

load.

To be clear, implementing a comprehensive range of resilience techniques, commensurate with a productiongrade system, is not necessary in this module. See the marking criteria in §5 for additional guidance.

NEWCASTLE UNIVERSITY Last modified: March 1, 2024 4

CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024

3.2.3 Dimension 3: Innovation

This final component assesses the innovation of your project; that is, how it provides new features, or addresses

new requirements, in a way that goes beyond existing secure chat systems.

Some ideas for novelty include:

1. Privacy-enhancing technologies: To what extent can differential privacy, private contact discovery, or

data obfuscation be applied in a novel way?

2. How could machine learning be integrated in your solution in a new way? For example, for detecting

fake/malicious clients or unauthorised users of devices in real-time (continuous user authentication)?

3. Information hiding: How can steganography be incorporated in a new way to covertly transmit secrets

in the presence of adversaries who may have access to messages?

4. Blockchain: To what extent could blockchain be used in a secure messaging system?

You may also express your innovation through the project’s engineering with clearly justified benefits. For

example, you may utilise a new network or system architecture (e.g. supporting decentralisation); using an

interesting network medium over which to communicate messages; using readily available hardware security

technologies to protect encryption keys; and more. This should be convincingly justified in your report.

3.3 Module Flowchart

To help your understanding of CSC8208’s structure, we illustrate the different stages and times in Figure 1.

4 Team Mechanics

To be successful in this module, it is critical to learn to work effectively within a team of people whom you

may not know. This is to replicate a real-world environment: just like the workplace, you may have never

worked with, or have even met, your teammates before this module. To this end, you will be stratified into

groups of approximately eight members each, comprising members from different M.Sc. programmes within

the School of Computing. Please note that the staff will allocate the teams; students will not be able to form

teams themselves. Changing teams is also prohibited unless there are exceptional circumstances with the

approval of the module leadership. This is to ensure diversity and consistency across teams.

4.1 Team Leader

Once you have been allocated to teams, it is imperative that you make contact as a collective as soon as possible.

Each team must nominate a leader whose responsibilities include:

? Arranging and leading group meetings. Includes physical/virtual meetings, setting agendas and delegation. It is important to re-emphasise that module staff are not responsible for arranging your team

meetings, nor can they expected to attend them.

? Submitting group assessments. To ensure consistency, each team leader shall submit assignments on

behalf of the group (literature review, presentation, and final group report).

? Planning the team’s activities. A concrete plan is an important component in ensuring that assessments

are submitted on time, with sufficient contingency measures, and that tasks will be delegated fairly

We expect each group to have nominated a leader and held their first meeting(s) by the end of the first teaching

week. A deputy leader is also required, who will assume the responsibilities of the team leader in a back-up

NEWCASTLE UNIVERSITY Last modified: March 1, 2024 5

CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024

Lectures

Group Allocation

Reading Papers

Project Theme Selection

Three Paper Reviews

Threat Model

Security Policy

Assessment 1 Submission

High & Low Level Design

Coding & Implementation

Testing & Evaluation

Assessment 2 Submission

Weeks 1 to 4

Week 1

Weeks 2-3

Weeks 3-4

4th March

Weeks 4-6

22nd March

Weeks 1-4

Weeks 4-6

Figure 1: Indicative module flowchart.

NEWCASTLE UNIVERSITY Last modified: March 1, 2024 6

CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024

capacity. The names of team leaders and deputy leaders should be submitted in your Microsoft Teams channel

by Week 2.

Submit progress update each week covering minutes of the team meeting and any concerns.

4.2 Project Supervision

As mentioned in Section 1, teams are expected to work independently with minimal supervision, similar to

the way in which your individual project (dissertation) supervisor may operate. However, you are not alone:

problems sometimes arise that prevent teams from functioning as expected. There are several ways in which

such issues can and should be raised. Firstly, it is critical that you make the most of the aforementioned tutorial

sessions. Please do not hesitate in raising queries/issues with the module staff during the scheduled tutorial

sessions. Within the short duration of the module, unresolved issues can quickly spiral into ones that affect

your grades. The Canvas discussion board functionality also serves as an appropriate forum for raising issues.

Lastly, if all other avenues of communication have failed, the module staff can be contacted via email.

4.3 Individual Contribution Formula

It is important in team-based modules to ensure that each member’s contributions are fairly reflected in the

overall marks. This must be done in a way that incentivises teamwork and collaboration, avoiding situations

in which one or two people do all of the work. This module uses the following guidance, which has been used

in previous years on CSC8208 and its sister module, CSC8113: “Group contributions should be agreed among the

group, and should be fair and truthful. They should sum to 100% and must be included in the group report.”

In other words, if a group has eight members, then an ‘ideal’ allocation is 12.5% per person to indicate that

everyone has contributed equally. However, it need not be ideal due to the different levels of engagement

between team members. A possible distribution could be 15%, 15%, 15%, 15%, 15%, 10%, 5%, and 10%.

In your decision-making process, please consider the significance of individual contributions. If the final

project report carries a weight of 70% of the overall module marks, and a group mark is given as 80/100, then

the report will carry 56/70 (= 70 × 0.8) towards the group’s mark.

Given eight members in a group, there are (56 × 8) = 448 marks to be distributed. Let us also assume each

member is named as A, B, C etc. Given an example of A = 15%, B = 15%, C = 15%, D = 15%, E = 15%,

F = 10%, G = 5%, and H = 10%, then the following allocation will be made for individual grades:

? A, B, C, D, and E will receive 15% of 448 = 67.2/70 = 96%.

? F and H receive 10% of 448 = 44.8/70 = 64%.

? G receives 5% of 448 = 22.4/70 = 32%.

Therefore, G will receive a failing grade for this assessment.

Considering that 100% is the maximum that a student can achieve, this methodology has some significant

consequences. Let’s assume the same situation in which the group has received 56/70 for their final report:

? Assume that four members, A, B, C and D, do all of the work, and their contributions are 25% each with

all other team members having zero contribution. In this scenario, A . . . D will thus receive 0.25 × 448 =

112/70 = 160%, while E . . . H will receive 0%. Because the assessment is ‘capped’ at 100% per individual,

A . . . D will receive 100% in practice; the additional amounts over 100% are lost.

? Freeloading on others’ contributions is penalised. Assume A . . . G contribute 14% each, while H contributes 2%. H will receive a failing grade in their individual mark (0.02 × 448 = 8.96/70 = 12.8%) while

A . . . G receive 0.14 × 448 = 62.72/70 = 89.6%.

NEWCASTLE UNIVERSITY Last modified: March 1, 2024 7

CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024

5 Marking Criteria

5.1 Literature Review, Threat Model, and Security Policy

This assessment aims to develop critical analysis and understanding of key research papers within the realm

of security, specifically focusing on subject areas such as privacy, performance, networking and blockchain.

Students are tasked with reviewing any three research papers from a pre-determined list of scholarly articles

provided by the module staff.

Along with the research paper reviews, students are required to submit a threat model and a security policy aligned with their chosen theme and research papers. The security policy should encompass preventive

measures, detection strategies and measures to maintain the security properties outlined in the threat model.

The mark scheme for this assessment is given in Table 1 at the end of this document.

5.2 Final Project Report

The final project report attracts the biggest percentage of any assessment (70%). It should describe your solution in the style of a scientific paper (IEEE Computer Society double-column journal or conference style). This

should give you a feel for how ‘real’ papers in computer science are composed. The template can be found

online or on Canvas.

The precise section headings are left for you to decide. However, in general, we expect that a good report

would comprise the following:

? The project’s aim, rationale and objectives, and a brief background of the research problem(s) that you

are solving.

? A literature review in the form of a ‘Related Work’ section written specifically on secure chat systems.

? How your system design and implementation addresses each of the three aforementioned dimensions:

1 security, 2 resilience, and 3 research novelty, as described in §3.2.

? How you evaluated your project.

? Your conclusion(s) and any directions for future research.

To guide the development of your project, the final report will be marked using the criteria in Table 2 at the

end of this document. This should set out the expectations for receiving the different grades. Good luck!

6 Helpful Advice

Some common issues have arisen in the past that have limited the success of teams’ assessments in this module.

These issues are described below in order to help you avoid them:

? Structure and focus your team appropriately. It makes little sense for every team member to be on

programming duties with nobody, for example, working on security engineering or research novelty. It

is generally a sound strategy is to focus efforts evenly, structuring the team to meet all elements of the

marking criteria. For example, you may wish to assign a resilience ‘lead’ to to one team member, security

to another, and so on. This will help balance your team while leveraging the strengths of each member.

? ‘Don’t roll your own crypto’. During the design and implementation of your project, it is important to

use established, rigorously tested security algorithms. Implementing protocols, or worse, cryptographic

algorithms from first principles is not necessary to be successful in this module. Always opt for an

existing libraries and protocol implementations over ones you build yourselves.

NEWCASTLE UNIVERSITY Last modified: March 1, 2024 8

CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024

? Make use of communication and collaboration tools. Working effectively in a team is essential to succeeding in this module. It is strongly advised to arrange frequent in-person or virtual meetings to help

make key decisions, delegate tasks etc. You may also wish to use Microsoft Teams, Slack, Discord, or

another platform to help coordinate your activities online. Github and other Git implementations are

also useful in managing code bases that involve a number of contributors.

7 Supplemental Background Reading

This module accepts students from a wide range of backgrounds and programmes. Some team members may

have a limited understanding of security, while others, such as those on the M.Sc. Cyber Security programme,

may have a large degree of knowledge. However, other members will have skills in other important areas,

such as cloud computing, which lends itself to the resilience dimension. It is vital that teams work effectively

to maximise the benefits of each other’s skill sets.

It is often desirable for everyone to have a broad understanding of what they are implementing. The following

resources are suggested as a introductory reference material. Note: these should be considered independently to the

papers that you include in your literature review!

? On research methods in computer science: J. Zobel, “Writing for Computer Science.” Springer, 2009 [2].

? On threat modelling: A. Shostack, “Threat modeling: Designing for security.” John Wiley & Sons, 2014 [3].

Chapters 1–3 are worth consulting for modelling threats in a standard fashion.

? On security and cryptographic engineering: N. Ferguson, B. Schneier, and T. Kohno, “Cryptography

engineering: Design principles and practical applications.” John Wiley & Sons, 2011 [4]. Chapters 1–2 and

18–20 may be of interest.

? Building modern resilient systems: H. Adkins et al., “Building secure and reliable systems: Best practices for

designing, implementing, and maintaining systems.” O’Reilly Media, 2020 [5]. See chapters 1–2 and 8–10.

Acknowledgements

A ‘thank you’ is due to the previous staff, particularly Dr. Steve Riddle, who helped make CSC8208 a success

in previous years. Also, thanks to Dr. Essam Ghadafi for permission to use the CSC8209 marking criteria from

which the final report’s mark scheme is derived.

References

[1] N. Borisov, I. Goldberg, and E. Brewer, “Off-the-record communication, or, why not to use PGP,” in Proceedings of the ACM Workshop on Privacy in the Electronic Society, pp. 77–84, 2004.

[2] J. Zobel, Writing for computer science. Springer, 3 ed., 2014.

[3] A. Shostack, Threat modeling: Designing for security. John Wiley & Sons, 2014.

[4] N. Ferguson, B. Schneier, and T. Kohno, Cryptography engineering: design principles and practical applications.

John Wiley & Sons, 2011.

[5] H. Adkins, B. Beyer, P. Blankinship, P. Lewandowski, A. Oprea, and A. Stubblefield, Building secure and

reliable systems: best practices for designing, implementing, and maintaining systems. O’Reilly Media, 2020.

NEWCASTLE UNIVERSITY Last modified: March 1, 2024 9

CSC8208 MODULE

HANDBOOK

(

V1.2) ACADEMIC

YEAR: 2023/2024

Appendix

Assessment 1 Criteria

We maintain a broadly flexible marking scheme for assessment one (30% of the overall module grade). The first element of the report—the paper summaries—

will be marked with respect to the components in Table 1. This will attract 20% of the overall module grade; each paper summary will carry 1/3 of this grade.

Table 1: Assessment 1 – Marking criteria breakdown.

Aspect Contribution (%) Description

Investigation methodology 30 Does the paper aim to answer any questions? What are these? If not, what do you think these

questions are? Why are these questions interesting to the general reader (not just yourself) How

does the paper answer these questions?

Critical evaluation 50 Provide a critical commentary on the work itself, focusing on the strengths and weaknesses. In

particular, the strengths of the work should demonstrate your understanding on the paper itself

and its merits. You should not justify your commentary based on the print-quality or formatting

of the work.

Open challenges and discussion 20 Write a discussion note about the paper itself, by presenting a list of topics or questions about the

paper, for the reader to consider. These should not be questions the paper has already asked, or

those you have written previously.

The remaining 10% is divided as follows:

? Threat model (5%): Give a succinct description of the attackers and attack methods with suitable justification (1/2 page).2

? Security policy (5%): Give a concise set of rules (bullet points) which can serve as the security requirements that if met, will successfully protect against

attackers (1 page).

2For the utmost clarity, the threat model and security policy should be written specifically with respect to your secure chat project, not the paper summaries.

NEWCASTLE

UNIVERSITY Last modified: March 1, 2024 10

CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024 Assessment 2 Criteria This assessment attracts 70% of the module. The mark scheme in Table 2 will be used. Table 2: Assessment 2 – Mark scheme. Component (%) Fail (0–39%) Borderline (40–49%) Pass (50–59%) Merit (60–69%) Distinction (70–100%) Introduction (10%) Irrelevant rationale, aims, objectives, or problems to be addressed. A present but unclear rationale; objectives are largely vague in scope. A clear aim and mostly realistic objectives; may be vague in places. Clear aim with specific, realistic, measurable ob- jectives; good rationale. Cogent, research-based aim and SMART objec- tives; excellent rationale. Background (15%) An absent or irrelevant consideration of related work; no connection to the aim and objectives. Limited coverage of es- sential literature; many relevant papers not in- cluded; vaguely relevant to the aim and objectives. Basic coverage of related literature; some relevant papers not included; a weak but clear link to the aim and objectives. Good coverage of related work, but largely de- scriptive or uncritically treated; a good link to aims and objectives State-of-the-art literature covered, understood, and critically reviewed; clear and compelling links to the aim and objectives. Security (15%) Solution mostly fails to meet any ‘must have’ se- curity requirement. Lim- ited awareness of relevant threats and mitigations. Vaguely addresses some ‘must have’ security re- quirement; largely flawed mitigations. Addresses the key secu- rity requirements; mitiga- tions may have shortcom- ings; sound threat model and security policy. Addresses the key secu- rity requirements; appro- priate and correctly im- plemented mitigations. Addresses key and 1+ other security require- ments; strong threat model, security policy; appropriate mitigations. Resilience (15%) Solution does not enable one-to-one communica- tion; not resilient under any scenario. Enables two-party com- munication at any one time; major issues under most realistic scenarios. Multiple simultaneous sessions; implements a stated resilience mecha- nism; may have issues under some scenarios. See ‘pass’ but with a compelling implementa- tion showing resilience under realistic scenarios. A compelling solution with multiple resilience mechanisms catering to realistic scenarios. Innovation (15%) No potential for innova- tion; badly executed ver- sion of a simple system. A working derivative of existing work; no mate- rial novelty. Some novelty, but minor or incremental in nature. Significant novelty; largely safe, conventional approach to a reasonable problem. Significant novelty; con- vincingly addresses a rea- sonable problem in an original, inventive way. Evaluation (15%) An irrelevant or missing evaluation. Limited justification of the project’s aims and objectives. No empirical evidence. Acceptable justification; empirical methods used to justify the project’s aims and objectives. Empirically-led eval- uation; may not meet real-world requirements. Convincing, empirically- led evaluation demon- strated under real-world requirements. Form (5%) Incoherent structure; ma- jor typographical issues; no listings or diagrams. Many typographical is- sues; poor structure, ref- erencing; poor use of list- ings and diagrams. Generally coherent; some typographical, referenc- ing issues; acceptable use of listings and diagrams. Easy to follow; only mi- nor presentation and ref- erencing issues; good use of listings and diagrams. Commensurate with a quality publication with very minor changes. Presentation (10%) Fails to demonstrate most project elements (motiva- tion, design, implemen- tation, evaluation, outcomes etc.). Covers most basic ele- ments of the project, but lacks significant depth and clarity; poor visual appeal. Covers all basic elements; lacks detail, visual ap- peal, or coherence in some places. Good structure, clearly communicates the main elements of the project in an appealing way; some level of critical analysis. Excellent structure, visual appeal, offering in-depth, insightful, critical analy- sis of the project.

NEWCASTLE UNIVERSITY Last modified: March 1, 2024 11