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 (Turnitin) 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 unlinkable 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 Users 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) Minimise computational costs on Users.
(R7) Minimise 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 authorise 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 Users 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. Analyse 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 analyse 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. Sample Answer and Guide to Workshop Task 1
Mengya Li
March 11, 2023
This document contains one sample answer to a task in the workshop (Task 1 on page
13 on the week 8 workshop slides), and a step-by-step guide as to how to give such an
answer. Please note: there is more than one possible answer to the task, and more than
one way to write it out. You can solve it in other ways. The important skill to learn here,
and in your practical assessment, is the method to solve such a task. The aim is to give a
technical solution to secure a network transmission and achieve satisfying effects.
Task 1 is: Amy uses CardA to pay for the order, by giving the order and her identity
and the card name to the bank B, and putting CardA to a card reader to access the private
key saved on it.
To see the other descriptions for the use case, please refer to the workshop slides.
1 Sample Answer
1.1 Assumptions
(A1) CardA has a pair of private/public key, PKCardA and SKCardA, issued by the
Bank, B. CardA has the private key stored on it, and can be accessed through a card
reader and read into a computer programme. Bank B holds a copy of the public key,
but it has deleted the private key after having generated it. NOTE: this assumption
is a rephrase of what is given in the question description. It is not an additional
assumption. The purpose of putting this in assumption is to provide more details as
this specific design needs, and to give the notation of the keys.
(A2) Bank B has a pair of public/private key, PKB and SKB, issued by a certificate
authority (CA). The certificate for PKB is CertB.
(A3) The CA is trusted by all entities in the network, i.e., certificates issued by the
CA with the CA signature can be verified by any entity in the network.
(A4) Bank B keeps a record of order number, vendor identity, payer information,
payment status and order time. This record is stored with confidentiality protection,
such as encrypting it with a key only the bank knows. NOTE: this assumption is
made for mitigating replay attack. This is a reasonable assumption to make for this
task because protecting information stored inside an entity, i.e., the bank in this
case, is out of the scope of the task, which is to protect data in transit in a network.
1.2 Design for Task 1
Task 1 requires the user Amy to send a message to the Bank B, to inform B that she wants
to pay for an order with CardA.
1
1.2.1 Security Requirements
To achieve this functional goal, A sends B a message consisting of the order, As identity
and the card name CardA to B. Because the order has a unique order number, the price to
pay, and the time the order is placed, and the order is signed by V using the private key
associated to PKV , the bank can know from the order what is the price to be paid, and to
whom it is going to be paid. With As identity given and the card name given, the bank
can know who is supposed to make the payment and which account to use.
In this message, As identity, card name CardA and order information are sensitive
information. Therefore, this sensitive information should only be known to the intended
receiver, and the message should be protected for confidentiality. In addition, the message
should have message authentication protection, so that the receiver can obtain the infor-
mation the sender intends to send, and it is indeed a message sent by the genuinely CardA
with the CardA present (as opposed to sent by someone who knows the name CardA).
NOTE: for the practical assessment, the requirements are already given in the brief.
For a full mark, you need to: at least make sure all those requirements are satisfied; and
add additional ones based on your message content IF needed.
1.2.2 Design Details
To achieve confidentiality, the message should be encrypted by the public key of the
receiver, bank B. This is to ensure that only the owner of the associated private key can
decrypt the message correctly and read the content. To achieve message authentication,
the encrypted message above should be signed with CardAs private key.
To send the message, first, A should get the public key of B. This is done by getting
Bs certificate, CertB, from CA, and verifying the public key on the certificate is authentic.
Then, A encrypts the order, As identity and card name CardA with the public key of B,
PKB. Then, A generates a signature on this encrypted ciphertext, by signing on it using
the private key of CardA, SKCardA. Then A sends the signed message to B.
When the bank B receives the message, it should decrypt the message with its private
key, SKB, and find the public key of CardA, PKCardA, in its storage. Then it verifies the
signature using PKCardA. If the verification is successful, it checks whether the message
is fresh. To do so, it checks the order time is recent enough, and check in the record of all
orders to ensure the combination of this order number and this vendor identity is unique
and has not been paid yet. NOTE: the combination is used for checking, to deal with the
case where two vendors accidentally generated the same order number.
1.2.3 Message Content
The following message is sent from A to B:
pay order request = Sig(SKCardA,Enc(PKB,order||IDA||CardA)), (1)
where SKCardA is the private key of CardA, PKB is the public key of Bank B, IDA is the
identity of A, and CardA is the name of the card A is using to pay. Enc(k,m) denotes
the encryption of plaintext m using a key k, and Sig(k,m) denotes signing a message m
with a private key k. NOTE: Here you should explain the notation you use in the equa-
tion. If some notations have been given before in assumptions or design details, you can
skip them here. You will not lose marks for explaining them twice; however, you will
lose marks if you do not explain a fair number of notations, or if you make contradictory
definitions, such as using the same notation for two different things.
2
1.2.4 Justifications
This message can send the necessary payment information, i.e., order information, payer
identity and payment card information, to the bank, while achieving confidentiality. This
is because the authentic recipient, B, should have the private key needed to decrypt the
encryption in the message, and therefore can obtain the plaintext. Only the authentic
B should have this key, therefore, only the authentic B is able to obtain the plaintext
information.
This message can achieve message authentication, because the signature can only be
verified if the private key of CardA is used to generate it on the message, and the message
has not been modified after the signing. This key should only be known by CardA, so
the signer and sender of the message must be the authentic CardA. The whole encrypted
payment information is signed, so none of the information can be modified without being
detected. The receiver, B, issued the public key of the signing private key, and keeps an
authentic copy of the public key. Therefore, the authentic public key will be used to verify
the signature, ensuring the verification is correct.
The message is protected from replay attacks, by using the unique order number and
vendor combination for checking for paying twice, and using the order timestamp to check
freshness.
1.2.5 Limitations and Future Work
In the design, the message is signed with the private key of CardA. However, the private
key is stored on the card, and can be read with a supported device, such as a card reader.
This weakens the binding relationship between the card and the card owner, A. That is,
whoever can access the private key of CardA may not be the genuine A, but someone who
has the card. If an attacker steals CardA from A, knows As identity and has a card reader,
the attacker will be able to use the card to make payment for themselves, pretending to
be A. Therefore, additional measures can be taken, to verify the identity of the person
making the payment, before the bank authorises the payment.
2 Steps to break down the task and come up with the
design
1. Understand the task: What does the task say you should do? Read the task and find
the goal; then find what to send/exchange to achieve the goal.
Task 1 says: Amy uses CardA to pay for the order, by giving the order and her
identity and the card name to the bank B, and put CardA to a card reader to access
the private key saved on it.
Task goal is to send the order, As identity, and card name (CardA) to bank B. In
other words, B should know this information by the end of it.
2. Find out the security requirements. What among the things to send needs to be
protected, and what is the purpose of the protection? This is the security properties
to achieve in this network transmission.
From the task goal we know: A will sends B the order, As identity (IDA), and card
name CardA to B. The sample answer decides all of this information is sensitive
and private, because A may not wish to let everyone know what A is buying, or A
is buying something, or A has this card. So, to protect sensitive information from
3
being known to entities A does not want to share the information with, the security
property we are looking for is confidentiality.
Then, because the goal is to let Bank B have this information, we want to ensure
Bank B gets the correct information as sent by A. This means we need message
integrity.
Then, because we do not want anyone who know the name of A and the card name
to just use this card to pay for their own order, we would like to ensure that B can
verify this message is actually from where CardA is present for the payment. So
we would like to have message origin authentication, to ensure this message comes
from somewhere CardA is present. (NOTE: compare this to the limitation given
above. This origin authentication deals with the situation where an attacker knows
As identity and CardAs name. The limitation is considering where the attacker
knows As identity, CardAs name and HAS THE CARD.)
So security requirements for this task: confidentiality, and message authentication
(integrity and origin authentication).
3. Find out what security measures you can use to satisfy the security requirements.
There is a table given in Chapter 1 of the reference book [1], attached below for
easy reference. NOTE: the book uses the term encipherment in a very loose man-
ner. Please pay attention in your assignment report and distinguish between encryp-
tion, message authentication, and digital signature. Please refer to the slides in the
relevant weeks for which term to use for what security properties.
For confidentiality, you need encryption.
For message authentication, you need MAC or signature.
4. How to apply the security measures?
4
https://dl.hiva-network.com/Library/security/Cryptography-and-network-security-principles-and-practice.pdf
For encryption, you already know you want to encrypt the order, As identity, and
card name. This is the input to your encryption function. Now you need an encryp-
tion key. As the purpose of the encryption is for only B to read the plaintext, the
key you choose should satisfy: A has the encryption key; Only B has the decryption
key; the ciphertext generated with the encryption key can only be decrypted with
the decryption key.
Read the task description to see whether there is a key given already. In this case,
there is none. So for there to be such a key, one solution is to add an additional
assumption, so that you have this key. (Another solution may be you negotiate a
key with what you already have; however, this will be more complicated. In your
assessment brief, there is a trusted authority for you to use if you need to make such
an assumption. So here we make use of the trusted authority given.)
The additional assumption should be reasonable in the scenario. A reasonable ex-
ample could be: Bank B has a pair of private/public key, and the public key has a
certificate issued by a CA.
With this assumption, we can perform the encryption. The encryption is done in
the following steps: (1) A gets Bs certified public key from the certificate; (2) A
encrypts the data that need to be confidential with Bs public key.
For message authentication, we look at the task description again. The description
has stated that the CardA has a pair of private/public key issued by the bank and
the bank knows the authentic public key. This means a signature of CardA can
be generated on the message using CardAs private key, and the message can be
verified by B using CardAs public key. There is no need for additional assumption
for this.
Then you write out the design details as above. It should have steps each entity takes
to finish the task. The design should state clearly: what operation each entity does
on its own, what they send to whom, what they do when they receive something, in
what order they do these steps.
5. How to compose the messages?
From above, the design says the message should send order, As identity and CardAs
name, encrypted by Bs public key, and signed by CardAs private key. So the mes-
sage should be:
pay order request = Sig(SKCardA,Enc(PKB,order||IDA||CardA)), (2)
where SKCardA is the private key of CardA, PKB is the public key of Bank B, IDA
is the identity of A, and CardA is the name of the card A is using to pay. Enc(k,m)
denotes the encryption of plaintext m using a key k, and Sig(k,m) denotes signing
a message m with a private key k. Here you should explain the notation you use in
the equation
6. How to justify? The justification you are making here is the design can achieve the
security requirements (and performance requirements, for the assessment). This
design for Task 1 should ensure confidentiality of the data A wants to keep secret
(order, As identity, and card name), and message authentication of all data sent to
B.
For confidentiality, this design and the message content show that only the entity
with the private key paired with PKB can decrypt the ciphertext and read the en-
crypted data. Only B has that private key, so only B can read that message.
5
For message authentication, only the signature generated on the ciphertext using
the private key associated to the public key B will use to verify the signature can be
validated by B. Only when CardA is present can a user extract the private key from
CardA and use it to sign. Therefore, the signature ensures the message is coming
from someone in possession of CardA, and the message has not be modified by
anyone else after being sent by the sender.
In terms of performance, the design should be examined in terms of computational
costs, communication costs, key management costs.
The computation in this design is a public-key encryption and a signature gener-
ation, on the users end, and public-key decryption and signature verification on
the banks end. Public-key encryption and signature are more computationally ex-
pensive than the symmetric-cipher-based solutions for the same security properties.
But because symmetric keys are not available in this task, and only one message ex-
change takes place in the task, it is cheaper to directly use public-key cryptography,
instead of using public-key cryptography to establish symmetric keys and then us-
ing symmetric-cipher-based solutions. NOTE: When a large amount of data is to be
exchanged between a pair of entities for a period (a session), it is preferable to use
public-key cryptography to establish symmetric session keys, so as to use symmet-
ric-cipher-based security measures to protect network transmission in the session.
The costs for the extra operations to establish session keys are compensated by the
costs saved by using symmetric cryptography instead of asymmetric cryptography
in the session. It is also preferable to establish symmetric session keys for a session
even if you have long-term symmetric keys in the first place, for reasons we have
explained in the workshop about key hierarchy (week 6 workshop).
For communication costs, only one message is sent, and minimum data are added
to the message besides the information that has to be sent.
For key management, on the users end, only one long-term key has to be kept
secret, the CardA private key.
7. Limitation and weakness: Check the protocol against some common threats.
For replay attacks: in the message, there is no timestamp or nonce used. However,
the order contains a unique order number, the order time, and the signature of ven-
dor. If the bank B saves the order it processes, with the vendor info, order number
and order time, and check every new incoming order against the paid ones, B can
detect if a certain order has already been paid for.
Impersonation: In the design above, the key used to sign the message is saved in
CardA. The signature can prove the genuine CardA is present when the payment
request is sent. But this does not prove it is the owner of the card who is making the
payment, just someone who has the card at the moment is making the payment. If
someone has stolen the card and has the hardware necessary to read the key from the
card, they can use this card to pay. Think of the real-world card payment process:
you enter card number, name and cvv to a website. All this information is written
on the card, so if you steal the card, you can pay from the card, even if you are not
the owner of the card. Therefore, this design has a vulnerability, which is someone
who has stolen the card from A can make payment pretending to be A.
This is why the exercise set the second task, for the bank to verify A in addition to
verifying the card is valid in Task 1.
6
References
[1] W. Stallings, Cryptography and Network Security: Principles and Practice. Pearson
Education Limited, 7th ed., 2017.
7
Sample Answer
Assumptions
Design for Task 1
Security Requirements
Design Details
Message Content
Justifications
Limitations and Future Work
Steps to break down the task and come up with the design image7.png
image8.png
image1.png
image2.png
image3.png
image4.png
image5.png
image6.png
