COMP4337/9337 Securing Fixed and Wireless Networks
Assignment specifications for T2 2024 (24T2)
Version 1.0
1. Change Log
v1.0: Released on 17th June 2024
o Draft specifications
2. Due dates:
Final report/code/demo video submission: 1700 Hrs Friday 2nd August 2024
3. Goal and learning objectives
For this assignment, your task is to implement a hybrid digital contact tracing protocol called “DIMY: Did I Meet You”. You should implement various components of the protocol by following the specifications listed in this document, and reading the reference document listed under the section references to understand the scope and working of the DIMY protocol. You can use multiple processes/threads/virtual machines running on one laptop/desktop (with Linux OS) to setup the implementation environment.
3.1 Learning Objectives
On completing this assignment, you will gain sufficient expertise in the following skills:
1. Understanding and implementing several security mechanism for privacy-preserving, secret
sharing, key exchange and confidentiality such as Diffie-Hellman key exchange, Shamir Secret Sharing, Hashing and Bloom Filters.
2. Learning how UDP/TCP socket-based communications take place.
3. Integration of various technologies to achieve Confidentiality, Integrity and Privacy.
4. Experience in implementing a real protocol.
4. Assignment Specifications
This section gives detailed specifications of the assignment.
4.1 COVID-19 and Contact Tracing
The outbreak of the COVID-19 pandemic has changed many aspects of everyone’s way of life. One of the characteristics of COVID-19 is its airborne transmission, which makes it highly contagious. Moreover, a person infected with COVID-19 can be asymptomatic, thus spreading the virus without showing any symptoms. Anyone who comes into a close contact (within 2m for at least 15 min) with an infected person is at a high risk of contracting the coronavirus.
Digital contact tracing applications aim to establish the close contacts of an infected person so that they maybe tested/isolated to break the chain of infection. The digital contact tracing app is typically composed of two main entities, the smartphones acting as clients and a back-end server. In this model, the smartphones of two individuals with tracing apps installed would exchange some random identification code (this identification code does not reveal any sensitive information about their actual identities) when they are in close proximity. The back-end is typically maintained by health organisations (or the government), and once a person is diagnosed with COVID-19, they can opt to share the local list of contacts stored on their smartphone with the back-end server to identify at-risk users. Digital contact tracing apps are not meant to replace the traditional manual contact tracing processes, rather, these have been designed to supplement the contact tracing process.
4.2 DIMY Digital Contact Tracing Protocol.
Download the reference paper [1] and read through it to understand various components of the DIMY protocol. Briefly, devices participating in DIMY periodically generate random ephemeral identifiers. These identifiers are used in the Diffie-Hellman key exchange to establish a secret key representing the encounter between two devices that come in contact with each other. After generating their ephemeral identifiers, devices employ the “k-out-of-n” secret sharing scheme to produce n secret shares of the ephemeral identifiers. Devices now broadcast these secret shares, at the rate of one share per minute, through advertisement messages. A device can reconstruct the ephemeral identifiers advertised from another device, if it has stayed in this device’s communication range for at least k minutes.
After the ephemeral identifier is re-constructed, DIMY adopts Bloom filters to store the relevant contact information. Each device maintains a Daily Bloom Filter (DBF) and inserts all the constructed encounter identifiers in the DBF created for that day. The encounter identifier is deleted as soon as it has been inserted in the Bloom filter. Devices maintain DBF on a 21 days rotation basis, identified as the incubation period for COVID-19. DBFs older than 21 days automatically get deleted.
For the back-end, DIMY utilises blockchain to satisfy the immutable and decentralised storage requirement. Once a user is diagnosed with COVID-19, they can volunteer to upload their encounter information to the blockchain. Health Authorities (HA) then generate an authorisation access token from the blockchain that is passed on to the device owner. The user’sdevice combines 21 DBFs into one Contact Bloom Filter (CBF) and uploads this filter to the blockchain. The blockchain stores the uploaded CBF as a transaction inside a block (in-chain storage) and appends the block to the chain.
Daily, the app will query the blockchain to perform. risk-analysis, checking whether the user has come in close contact with any person diagnosed positive. A device combines all of the locally stored DBFs (the maximum number is limited to 21) in a single Bloom filter called the Query Bloom Filter (QBF). The QBF is part of the query that gets uploaded to the blockchain. The blockchain matches the QBF with CBF stored as a transaction in the blockchain and returns “matched” or “not matched” as a response. If the response from the blockchain is negative, the device deletes its QBF. Conversely, if the user is found to be at-risk, the user is notified, and the QBF is stored separately for further verification by HA in the follow up manual contact tracing process.
4.3 Implementation Details
In this assignment, you will implement the DIMY protocol with a few modified parameters.
Note that in this specification, the term ‘node’ refers to an instance of the DIMY protocol implementation (client) running on your laptop/desktop. Your main front-end program should be named Dimy.py. Note that you also need to implement the backend centralised server that should run on your laptop/desktop. Your backend server code should be named DimyServer.py.
This assignment specification has been modified to use TCP/IP protocol stack-based message passing instead of BLE communication. It also uses different parameters as compared with the original specifications listed in reference paper [1]. This is to cut down the development, testing and demo time for the assignment. The marking guidelines appear at the end of the assignment specifications and are provided to indicate the distribution of the marks for each component of the assignment.
Assignment Specification
We will follow most of the original specifications from the reference paper [1] except the changes that are listed in this section. There are three major differences: 1) We will employ UDP/TCP socket-based message passing between the nodes instead of using BLE communication. 2) We use different parameters values described in detail later in this section. 3) You are required to implement a simple centralised server acting as the back-end server instead of the Blockchain proposed in the reference paper. For details, please go through the subsection on the backend server.
In DIMY protocol, each node performs the following steps to broadcast and register a shared secret key representing an encounter with other another node in close proximity. We have listed these in form of tasks you will be assessed on.
Task 1: Generate a 32-Byte Ephemeral ID (EphID) after every 15 sec. Note that the reference paper proposed a 16-Byte EphID due to limitation on the size of a Bluetooth message broadcast.
Task 2: Prepare n chunks of the EphID by using k-out-of-n Shamir Secret Sharing mechanism. For this implementation, we use the values of k and n to be 3 and 5 respectively.
Task 3: Broadcast these n shares @ 1 unique share per 3 seconds. For this implementation, you are not required to use Bluetooth message advertisement, rather you can use simple UDP broadcasting to advertise these shares. Also, you do not need to implement the simultaneous advertisement of EphIDs proposed in the reference paper [1].
Task 3a: Implement a message drop mechanism that drops a message which is ready to be transmitted with probability 0.5. This should be implemented at the sender. Hint: generate a random number between 0 and 1. If this number is less than 0.5, don’t transmit that message (chunk).
Task 4: A receiver can reconstruct the advertised EphID, after it has successfully received at least k shares out of the n shares being advertised. This means that if the nodes have remained in contact for at least 9 seconds and received >= 3 shares of the same EphID, it can reconstruct the EphID. Verify the re- constructed EphID by taking hash and comparing with the hash advertised in the chunks.
Task 5: The node proceeds with applying Diffie-Hellman key exchange mechanism to arrive at the secret Encounter ID (EncID).
Task 6: A node, after successfully constructing the EncID, will encode EncID into a Bloom filter called Daily Bloom Filter (DBF), and delete the EncID.
Task 7: A DBF will store all EncIDs representing encounters faced during a 90-second period. A new DBF is initiated after the 90-second period and each node stores at most 6 DBFs. DBF that is older than 9 min from the current time is deleted from the node’s storage. Note that in original specifications DBF stores a day worth of EncIDs, but for this demo we will use DBF to store EncIDs received in 90-second windows.
Task 8: Every 9 minutes, a node combines all the available DBFs into another Bloom Filter called Query Bloom Filter (QBF).
Task 9: Each node sends this QBF to the backend server, to check whether it has come in close contact with someone who has been diagnosed positive with COVID-19. The node will receive the result of matching performed at the back-end server. The result is displayed to inform the user. You are required to use TCP for this communication between the node and the back-end server.
Task 10: A user who is diagnosed positive with COVID-19, can choose to upload their close contacts to the backend server. It combines all available DBF’s into a single Contact Bloom Filter (CBF) and uploads the CBF to the backend server. Once a node uploads a CBF, it stops generating the QBFs. The node will receive a confirmation that the upload has been successful.
Task 11: This task performs simple security analysis of your implementation of the DIMY protocol.
A) List all the security mechanism proposed in the DIMY protocol and explain what purpose each of the mechanism serves.
B) There are two types of communications in the DIMY protocol: i) Nodes communicate with each other using UDP broadcasts. ii) Nodes communicate with the backend server using the TCP protocol. Create an attacker node by modifying your implementation of the DIMY frontend. This code is named Attacker.py. Assume that this node can receive all of the UDP broadcasts from other legitimate nodes. Think of one attack that can be launched by this attacker node. Implement this attack and show how this attack affects the DIMY nodes.
C) Now focus on the communication of nodes with the backend server. Again, think of one attack that can be launched by the attacker node assuming the communication is not encrypted and the attacker node can listen to any node communicating with the backend server. Explain how this attack affects the working of the DIMY protocol. Note that you do not need to implement this 2nd type of attack on communication with the backend server.
D) Finally, suggest measures (if possible) that can be implemented to prevent the attacks you identified in B and C above for both types of communications.
General:
o Your front-end implementation should work in the debugging mode displaying messages sent and received, operations performed and state of Bloom filters in the terminal to illustrate that it is working correctly.
o Use UDP message broadcasting to implement send and receive functionality.
o DBF, QBF and CBF are all of size 100KB and use 3 hashes for encoding.
o You are required to run the assignment with three nodes running the DIMY frontend (plus the attacker node in Task 11) and one back-end server.
Back-end Server
Your client implementation interacts with a backend-server to send CBF/QBF and receive the results for the risk analysis performed at the back-end. Note that, you are not required to use a blockchain-based implementation, rather, you can use a simple centralised server to interact with the front-end.
• The backend server program is deployed in your laptop or desktop machine using TCP port No 55000.
• You can provide the information regarding IP address and port No of the backend server to your front-end client program through command line arguments. For example, Dimy.py 192.168.1.100 55000, where server is running on IP 192.168.1.100 and port No 55000 or you can opt to hard code this information at the front-end.
• The nodes establish a new TCP connection with the back-end server to transfer CBF/QBF to the server and receive the results of the queries.
• The back-end server stores all the received CBFs and can perform. matching for each QBF received from devices. It informs the node that has uploaded the QBF about the result of matching, matched or not matched. If there is no CBF available, the back-end returns not matched.
5. Additional Notes
• Groups: You are expected to work in groups composed of maximum two students. Use the same groups that you have formed for the labs.
• Use Python to implement this assignment.
• You are required to develop and test the implementation on your own laptop/desktop instead of using the CSE login servers.
• You are free to design your own format for messages exchanged between the nodes and the back-end server. Just make sure your front-end and back-end programs can handle these messages appropriately.
• You are encouraged to use the course discussion forum on Ed to ask questions and to discuss different approaches to solve any issues faced during the implementation. However, you should not post any code fragments on the forum.