Module Code

COM00162M

General Marking Criteria

Marks are awarded for the quality of your discussion and justification of your assumptions,
choices, and conclusions.

You are expected to research your answers and to cite appropriate external sources if required.
References must be listed at the end of the submission.

The IEEE format of citation and referencing must be used.

Assessment Component Weighting

This component will constitute 50% of your final mark in this module.

Special Module Requirements

To pass the module, students must achieve a pass mark in both assessment components.

Learning Outcomes

At
Youthe end
will be of theto:
able module the students will be able to:

• demonstrate a competent technical understanding of a range of emerging advanced

topics in cybersecurity.

• critically analyse the latest research in an area of cybersecurity.

• summarise the important technical aspects of the state of the art in an area of
cybersecurity for a technically literate audience.

• survey new and emerging methods from an advanced area of cybersecurity to identify
their applications to important classes of systems from the CyBoK, as well as their
underpinning assumptions and limitations.

Page 12 of 8
 Module Code
COM00162M

Question 1: Defending against DoS attacks in SDN (25 Marks)

(i) [8 marks] Identify one type of DoS attack (of your choice) in SDN. This must be based on
a single academic paper (journal or conference), but can be modified and enhanced with
your own assumptions, ideas, and design choices. Explain how the attack works.
Describe the attack using message sequence diagrams and flowcharts. Include
information such as the attacker’s objectives and capabilities, target(s) of the attack, and a
diagram of the considered network topology. Specify the assumptions so that the attack
can be successful. Explain the role of all the relevant elements and components. Explain
why you think that these are reasonable assumptions. Make it clear which content/ideas
have been borrowed from the academic paper and which are yours. Include an Appendix
with the definitions of all security-related and SDN-related terminology that you have used.

(ii) [17 marks] For the DoS attack type described in the previous part, design a defence
mechanism. This design can be based on one or more academic papers (including the
paper used in the previous part if you want) and can be enhanced with your own ideas.
Explain how your defence solution works. Specify any new (or modified) components or
elements and explain their functionality using flowcharts and tables (e.g., Flow Tables of a
Switch). If your solution involves new (or modified) network traffic, explain it using
message sequence diagrams. Explain why you think that this solution will be effective
against the considered DoS attack type. Discuss any impact on the Quality-of-Experience
of legitimate users. Make it clear which ideas have been borrowed from the academic
paper(s) and which are yours. Add to the Appendix any new security-related and
SDN-related terminology that you have used.

Page Limit

Your answer to this question must not exceed 1 side of A4 in total.

Diagrams, Tables, Appendices, and References do not count towards the page limits.

Specific Guidance

Diagrams and Tables must be created by the student

yourself e.g.(not copy-pasted
using from
draw.io (not papers), must
copy-pasted from be of
papers), must be of
good quality, relevant to the text, must be informative, and must not include irrelevant or useless
information. Diagrams and Tables must be appropriately labelled, explained, and referenced
within the text. Diagrams and Tables can include numbers, keywords, and labels, but not lengthy
sentences.

Answers must be typed and Diagrams and Tables must be produced using specialised computer
software (not handwritten and scanned).

Page 23 of 8
 Module Code
COM00162M

Question 2: Zero Knowledge (25 Marks)

In this question we will investigate why honest-verifier zero-knowledge does not imply
zero-knowledge for arbitrarily cheating verifiers.

(i) [6 Marks] Define what a zero-knowledge protocol is.

(ii) [3 Marks] What is special soudness?

(iii) [12 Marks] Consider the protocol in Figure 1 below.

Figure 1: Diagram of the protocol in Question 2.

Show that this protocol is complete, special sound, and honest-verifier zero-knowledge.
Justify your answers.

(iv) [4 Marks] Show that the protocol is insecure against cheating verifiers.

Page Limit

Your answer to this question must not exceed 2 sides of A4 in total.

Page 34 of 8
 Module Code
COM00162M

Question 3: Post-Quantum Cryptography (24 Marks)

According to the report published by NIST in July 2020 (see reference below), the proposals that
made it to the third-round finalist public-key encryption and key-establishment algorithms are
Classic McEliece, CRYSTALS-KYBER, NTRU, and SABER. The third-round finalists for digital
signatures are CRYSTALS-DILITHIUM, FALCON, and Rainbow. These finalists will be
considered for standardisation at the end of the third round. In addition, eight alternate candidate
algorithms will also advance to the third round: BIKE, FrodoKEM, HQC, NTRU Prime, SIKE,
GeMSS, Picnic, and SPHINCS+.

Pick three different proposals from the list above, including lattice-based, multivariate-based, and
code-based primitives, and state the advantages and weaknesses of each, in all areas of
provable security, suitable parameters, analysing previously proposed attacks, performance time
and space complexity among others.

Reference

“Status Report on the Second Round of the NIST Post-Quantum Cryptography Standardization
Process” by Alagic et al., National Institute of Standards and Technology report NISTIR 8309,
2020. Available at:

• https://csrc.nist.gov/publications/detail/nistir/8309/final

• https://doi.org/10.6028/NIST.IR.8309

Page Limit

Your answer to this question must not exceed 3 sides of A4 in total.

Page 45 of 8
 Module Code
COM00162M

Question 4: Human Factors (26 Marks)

Unauthenticated key exchange protocols, such as the plain Diffie–Hellman protocol, are prone to
man-in-the-middle attacks. In this attack, the adversary communicates with Alice and Bob by
positioning itself in the middle of their communication channel.

If there is no man-in-the-middle attack, in a key exchange protocol Alice (A) and Bob (B)
communicate their public keys pk A and pk B to each other and then generate a shared key
between them from their own secret key and the other side’s public key.

In a man-in-the-middle attack, the adversary M generates two public keys pk 1M and pk 2M . The
adversary makes Alice believe that Bob’s public key is pk 2M instead of Bob’s real public key pk B
and makes Bob believe that Alice’s public key is pk 1M instead of Alice’s real public key pk A . As
a result, there will be one shared key established between A and M, and another shared key
between M and B.

Although Alice and Bob cannot prevent this attack, if they have access to another secure channel
of communication that M cannot intercept, they can detect that such an attack has happened by
comparing the public keys they believe belongs to the other side. For example, if both
concatenate the public keys they believe belong to Alice and Bob (in this order) into one string, if
there was no attack they both will get the same string pk A k pk B , but if there was an attack Alice
will get pk A k pk 2M but Bob will get pk 1M k pk B . So, if they compare the strings they get via
another secure channel and find out they have different strings, they will detect that there was an
attack and can discard the shared key.

WhatsApp uses the Signal protocol for key exchange to establish shared keys between devices
for end-to-end encryption of messages. The main channel of communication between users is
through WhatsApp servers. WhatsApp servers send Alice’s public key to Bob and Bob’s public
key to Alice. The key exchange protocol is not authenticated, so it is prone to man-in-the-middle
attacks from either third parties or WhatsApp servers themselves.

To be able to detect such attacks, WhatsApp allows users to verify that they have the same keys
with other users through either scanning a QR code (if the two users are in the same place) or
comparing two 60-digit numbers called ‘security codes’ (for example by reading the security
codes to each other over the phone). These security codes follow a similar idea to the
concatenated strings described above, but provide a shorter representation for usability. In this
question, we consider the security and usability of comparing the 60-digit WhatsApp security
codes.

(i) [4 Marks] Consult the WhatsApp documentation (or any other reliable sources) and
explain how the 60-digit security code is generated. Your explanation should not just be a
copy of the documentation. The explanation should for example give a formula (or
formulas) for the computation of the security code or a diagram explaining the steps of the
computation. Recommended pieces of WhatsApp documentation are the End-to-End
Encryption FAQ page (see reference below), especially the section on ‘Verifying Keys’ in

Page 56 of 8
 Module Code
COM00162M

the white paper cited in the FAQ page. Note that in WhatsApp documentation, (long term)
public keys are referred to as ‘public Identity Key’.

Consider the scenario in which WhatsApp carries out a man-in-the-middle attack against a pair
of users and wants this attack to remain undetected. WhatsApp can generate many keys and
hope that for a one pair of these keys the computed security codes for the two users will be the
same, so they cannot detect the attack even if they do the verification.

Intuitively, in the above attack WhatsApp does not necessarily need to be able to get the exact
same security code for both users to succeed, because some proportion of users might just think
that the security codes are the same if they are sufficiently similar. Besides, the security code
can be shown to users using other representations, for example hexadecimal digits instead of
decimal digits, and that might have an impact on the usability and security of the verification.

Dechand et al. (see reference below) have investigated the usability and security of verification
tasks similar to WhatsApp’s for different representations. They call the strings that are compared
by users in the verification task ‘key fingerprints’, because they are usually short representations
(i.e. ‘fingerprints’) of long cryptographic keys. The consider 112-bit fingerprints and attack
fingerprints in which the first 24 and last 24 bits are the same (between two key fingerprints that
Alice and Bob calculate) and of the remaining 64 bits in the middle, 32 bits are also the same.

(ii) [10 Marks] Based on Dechand et al.’s results, discuss estimated metrics for the usability
and security of WhatsApp security code verification. Make sure you consider different
aspects of usability as well as different aspects of security.

(iii) [12 Marks] Assume that you want to investigate the usability and security of WhatsApp
security codes of different lengths shorter than 60-digits. A use case of such shorter
codes is in scenarios where the risk of man-in-the-middle attacks is low, for example when
pairing your smartphone to your smart TV. Design an experiment that measures the
usability and security aspects of such security codes for, say, 3 different lengths. Make
sure you specify the experiment steps including the tasks participants need to carry out
and any measures ensuring validity, your independent and dependent variables and how
you measure them each, and the analysis methods. Brief reasoning for design choices
needs to be included.

References

“An empirical study of textual key-fingerprint representations” by Dechand et al. presented at

USENIX Security 2016. Available at:
https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_dechand.pdf

“About End-to-End Encryption”, WhatsApp FAQ page. Available at:

https://faq.whatsapp.com/general/security-and-privacy/end-to-end-encryption

Page 67 of 8
 Module Code
COM00162M

Page Limit

Your answer to this question must not exceed 2 side(s) of A4 in total.

Diagrams, Tables, and References do not count towards the page limits.

End of examination paper

Page 78 of 8