1. Submission guidelines
All submissions should be done through Blackboard only.
What to submit
1. A report of your design (per group). More detailed description is given in Section 2.5.
2. An individual reflection on the group work (each student). The reflection should include your individual contribution to the group work, your evaluation of your own performance in the group work, and your evaluation of your performance as a group.
All submissions should be a PDF file, generated with MS Word or Latex format. The submissions should only contain all required elements and must be submitted using Blackboard (Turn it in) by the deadline. Please give yourself plenty of time when uploading your assignment on Blackboard as submissions after the deadline date and time will incur the usual late submission penalties. Please note that other document formats are not accepted.
2. Assessment task details and instructions
This assignment is half of the formal assessment and is therefore compulsory. Read this document carefully and make sure you are clear about what you have to do, and what you have to hand in, before you attempt the assignment.
This assignment is a group work. It should be done by a group of 2 people only.
You are required to design a set of security & privacy solutions for the following use case, and complete the given tasks.
2.1. Use case descriptions
Many healthcare providers have started to provide online services for patients to access their services more easily. However, providing online access is accompanied with an array of security and privacy concerns. In this section, we describe the use case of a patient medical information access system.
The system consists of the following entities:
1. User: He/she is a patient who uses healthcare services.
2. Healthcare provider (HP): an HP is a provider of healthcare services. There are more than one HP in the system. Each User can use services from more than one HP.
3. Research Institution (RI): an RI uses the medical information of patients to conduct medical research. They may request medical information from HPs.
The entities are connected with public networks, such as Internet. That is, the communications between them are publicly accessible and insecure, if no additional measures are taken.
The entities in the system want to have the following 2 services:
1. Online Healthcare Service: this service is provided by HPs to Users. To use an Online Healthcare Service, a User first registers with an HP of their choice. In the registration, the User creates an account with a Unique User Identifier (UUID) at the HP, together with a password, pwd. The HP saves the UUID (denoted as UUID), a nonce (denoted as r), and hashed _credential = h(r||h(UUID||pwd)) in their User Account List. Later, when the User wants to use the Online Healthcare Service provided by this HP, they will use their UUID and their password to authenticate. After authentication, the User will send and receive their own private medical information with the HP.
2. Medical Research Data Collection: This service is provided by HPs to RIs. When using a Medical Research Data Collection service, an RI sends requests for data to one or more HPs. This service provides two levels of access privilege to RIs: linkable medical data access (L1), and unlikable medical data access (L2). With L1 access, RIs can get medical data that are linked
to the same User. With L2 access, RI can get medical data that cannot be linked to the same User. However, neither access levels can allow the medical data to be linked to the UUID.
Additional specifications on the services:
1. User consent of sharing medical data: when Users are registered for the Online Healthcare Service for each HP, User will opt for whether or not they are willing to share their medical data with RIs, and whether the data will be shared with L1 access or L2 access.
2. Medical data request rules: RIs which have L2 access request medical data with keywords such as disease name, time period (i.e., medical data collected from a start time to an end time), or location range (i.e., medical data collected from patient in a given city/town). HPs will reject requests made by RIs which only have L2 access if the requests are asking for linkable or identifiable information, such as a User’s name. RIs which have L1 access can request any data that RIs which have L2 access can request. In addition, they are allowed to request with a keyword such as an identifier they know that belongs to a User, without knowing the identifiable information (i.e., UUID or real name) of the User.
2.2. Requirements
In this use case, we aim to achieve the following security & privacy requirements:
• (R1) Mutual authentication: whenever two entities communicate, they should be able to verify that the other entity genuinely has the identity they claim to be.
• (R2) Data confidentiality: any personal information or medical information should only be known by the designated receiver.
• (R3) Data authenticity: any data received should be verified that it has been sent by the authentic sender and it has not been modified during the transmission.
• (R4) Access control: RIs should only be able to access the data they are allowed to obtain.
• (R5) Identity privacy: if a User is using Online Healthcare Service provided by two different HPs, i.e., the User has a different account at each of the HPs, the HPs should not be able to link the accounts to the same User. RIs should not be able to know the account information of any Users (e.g., UUID), regardless of their access level.
In addition to the security requirements, we aim to achieve the following performance requirements:
• (R6) Minimize computational costs on Users.
• (R7) Minimize communication costs on all entities.
2.3. Tasks
• (T1) State the assumptions you use in your designs.
• (T2) Design a solution to mutually authenticate Users and HPs securely, for Online Healthcare Service.
• (T3) Design a solution to secure the medical data transmission between Users and HPs, for Online Healthcare Service.
For T2 and T3, security requirements R1, R2, R3 and R5 must be satisfied, and you should explain and justify how your solution satisfies these requirements. You should also explain how performance requirements (R6-R7) are satisfied, and justify your decisions in making the design.
• (T4) Design a solution to mutually authenticate HPs and RIs securely and authorize correct level of access to RIs, for Medical Research Data Collection.
• (T5) Design a solution to secure the medical data request and response process between HPs and RIs, for Medical Research Data Collection.
For T4 and T5, all security requirements (R1-R5) must be satisfied, and you should explain and justify how your solution satisfies these requirements. You should also explain how performance requirements (R6-R7) are satisfied, and justify your decisions in making the design.
• (T6) Identify any weaknesses or limitations in your designs and give any recommendations as how the weaknesses/limitations may be overcome.
For each of the design task (T2 – T5), you should write:
– A clear description of the methods you use to solve the problem, e.g., the steps which the solution takes to satisfy the requirements.
– Messages the entities need to send and receive to facilitate the solution. The message content should be clearly given, and be clearly explained how they are used to achieve the requirements above.
– Clear and convincing justifications of how your design satisfies the requirements.
– Clear and concise evaluation of performance, i.e., in terms of computational costs, communication costs, and key/credential management costs.
2.4. Preliminaries
We give you some tools or building blocks you can use to build your design. You can choose to use them or not.
• (BB1) cryptographic tools: You have access to cryptographic techniques learned in the course module. That is, you can use random number generator, cryptographic hash functions, symmetric cryptosystems, and asymmetric cryptosystems. You are allowed to use other cryptographic techniques from your own research into literature, but you have to provide sufficient information, written in your report, to clearly explain how they work, how you use them in your design and why you use them.
• (BB2) There is a central trusted authority available to the system, which is guaranteed to be neutral, will not collude with anyone, will not violate User’s privacy, and is allowed to issue certificates.
2.5. Report style
Please write in an academic style, i.e., write in concise and precise English, have a good logic flow, avoid meaningless or irrelevant information, avoid repetition, avoid grammar mistakes. It is good to follow the instructions regarding language as given in your research assignment template.
Please write in single column.
It is recommended that your report has a structure like the following example, although it is not compulsory:
Section 1: Assumptions
Section 2: Design for T1
Subsection 2.1: design description
Subsection 2.2: messages
Subsection 2.3: justifications and evaluation
Section3: Design for T2
Subsection 3.1: design description
Subsection 3.2: messages
Subsection 3.3: justifications and evaluation
…
Section 6: Limitations
[Section 7: References]
Suggestions to improve your work: following are main issues in students’ submissions that can be addressed easily:
• Plagiarism is not allowed. For example, copying text from other articles and/or websites without rewording should be avoided. You should rephrase the source materials you are using in your paper.
• If you use anything that is not included in course materials, please give sufficient evidence to support your arguments, i.e., explain the arguments and evidence in the report, and give references.
• References must be well managed. This includes using a standard reference style (such as IEEE reference style), using a reference that is relevant, using references from reliable sources, etc.
• Assumptions must be reasonable, and NOT contradictory to what is given in the problem description. For example, do NOT assume all communication channels are already secure.
• Please write in a concise and precise manner. Avoid remarks that are dubious, ambiguous, inaccurate, or that you cannot defend well if questioned. Give enough details to avoid misunderstanding. Use concepts/terms/notations correctly. If you define something that is new, please make the definition clear and concise.
• Requirements must be satisfied, and justifications must be sufficient, logical and convincing. Design choices must be explained.
Assessed intended learning outcomes
On successful completion of this assessment, you will be able to:
Knowledge and Understanding
1. Model a range of threats and apply cryptography for protecting networked systems and users against real-world attacks.
Practical, Professional or Subject Specific Skills
1. Think like an adversary, demonstrating possible attacks to networked systems by exploiting assumptions made during system design and implementation.
2. Take a critical approach to research, development and maintenance of advanced networking systems.
3. Analyze security/privacy challenges in diverse applications and propose countermeasures.
Module Aims
1. To provide a detailed understanding of diverse threats to, and attacks on, networked systems;
2. To study emerging networked systems and their security challenges, e.g., IoT, Cloud, blockchain, etc;
3. To define the concept of privacy, and to identify its challenges and its legal and social aspects;
4. To analyze the use of cryptographic algorithms in implementing secure network communications and in preservation of privacy.
Word count/ format
Your submissions should be in single column, no more than 3,000 words (excluding figures, tables and references). This should be equivalent to 6-7 A4 pages in single column format.
All figures should be focused, have good quality, and appear in appropriate locations. Please make sure all figures and tables are cited in-text. Please carefully proofread and avoid grammar errors and spelling errors.
