Description
This project is composed by two sub projects, and will focus on the implementation of a robust protocol for handling a trustworthy shuffling of a set of participants. Implementation will consist of a server (clerk) and multiple clients (participants) communicating over a network.
There are numerous applications for this kind of work. For instance, when adversaries are matched with each other for a competition, they can be first randomly shuffled in different sets and then matched between sets (e.g. first with first, and so on). It can be use to set a random priority order among people when no other criteria is applicable.
The first sub project will correspond to the implementation of the processed described, without any mandatory use of citizen card, asymmetric keys, or encryption. This implementation will also have vulnerabilities, which must be analysed and fixed, Any CWE with CWE-310, CWE-320, CWE-1214, CWE-19, CWE-1215, or CWE-707 as its ancestor can be used as a basis for the vulnerabilities. The CVSS of the vulnerabilities should be at least 20 points.
The second sub project will correspond to the implementation of a cryptographicaly secure application, exactly as described, without known vulnerabilities.
Each sub-project awards 5 points to the practical component.
Random shuffling: the problem
There are numerous ways we can randomly shuffle a group of people, but usually the targets do not participate in the process. Instead, they need to trust on some system, run by others, and on their correctness. This facts have the potential to reduce the trust on the legitimacy of the outcome, allowing for protests.
In the secure protocol that you have to develop, each participant has influence in the result, while not being able to device for a given outcome, and can verify what other did, and if they did it right. In other words, each participant can guaranty that the outcome depends on its own actions, which can be verified by others, but cannot decide in which specif positions each participant will be at the end of the protocol. This enforces simultaneously randomness and trust on the legitimacy of the outcome.
Shuffle area
We consider the existence of a shuffling area (SA), run directly by a clerk, to which all participants connect and acts as a trustworthy organiser. It does not interfere with the outcome itself, but makes information available to all, implements authentication and authorization.
When the process starts, the SA shall not accept more participants.
The SA has a asymmetric key pair which it uses to sign messages exchanged or forwarded. Its public component is assumed to be well-known by all the participants.
The SA area will also record all messages exchanged, and actions executed. The log is composed by entries with the following format:
sequence, timestamp, hash(prev_entry), text, signature
Participants can request this log and audit the events.
The sequence is a monotonically increasing integer denoning the order of the message.
The timestamp is number representing the time since the EPOCH.
The text field contains a text version of the message exchanged, including source, destination and other contents.
The hash is any suitable hash function to build a hash chain.
The signature is a signature created by the clerk.
Participant Identification and Registration
Upon connection to the SA, participants must be authenticated and authorized. Any Portuguese citizen can play, as proved by the use of their citizen card. One specific user can become a clerk.
Each participant will be identified by a unique sequence number (starting from 1), a public key and a nickname.
Each participant’s public key belongs to an asymmetric key pair generated to itself just for participating. This key is provided to the clerk during the login process, and is considered to have a short duration.
A participant’s authentication process must ensure a commitment of the user public key and nickname. This means that attackers cannot tamper the public key registered by a user, or replay the process. Digital signatures and password-based message authentication codes (depending on the authentication process) are common solution to implement that commitment.
The SA should sign the data from all users sequence number, nickname, key
As a simplification of this process, if students do not wish to implement support for the Citizen Card, a custom PKI may be used. This option will not award full points.
Use of a software citizen card, as used in the practical classes, will award full points.
Random shuffling of registered participants
The process starts by the SA shuffling $N$ numbers, from 1 to $N$, were $N$ is the number of participants, and encrypting each number with a symmetric key. The result, which we will call a deck (of numbers), is signed and logged. Following the order of their registration, each participant will take that deck, encrypt individually each number, reshuffle the numbers, sign the deck and post the result to the SA, which logs it. It is important that each signature includes the participant number.
This way, the individual numbers will be shuffled and encrypted by all participants (and the SA), and then made available to all of them. No participant has access to the numbers in order to cheat, and all have the opportunity to shuffle the deck to some unknown order, which can be validated by the signatures provided.
Finally, all participants and the SA provide their symmetric keys to all the others, for the distributed calculation and validation of the shuffling outcome.
Participants can use the keys, in reverse order, to decrypt the deck and check if each decrypted version (properly unshuffled, which means checking number by number) corresponds to the one that was committed by the correct participant. Upon all decryption steps, all participants must reach a shuffled version of the encrypted deck provided by the SA in the beginning. Finally, using the SA key, they can decrypt this deck and get the final order of all the participants.
Digital signatures on exchanged data
All the messages produced by participants must be signed by them, before being transmitted. The public keys used to verify participants’ signatures must be conveyed to the SA during the registration of a participant. Thus, when a shuffling process starts, all the participants know the public keys of all the participants (and the SA).
The SA should publish the shuffling outcome as a signed message. The public key to validate the signatures should be well-known to the participants. This way, participants can abandon a shuffling process after receiving an invalid message (with a wrong signature) received from the SA.
Trust in the SA
The SA is trusted not to cheat. Upon the revelation of the symmetric encryption keys, the SA has the power to detect cheaters and abort the shuffling process. The SA also has the power to abort a shuffling process upon detecting a wrong participant signature that compromises the continuation of the protocol.
List of keys that must be used
The following different keys must be used:
-
A fixed, well-known, asymmetric key pair for the SA. Used to sign messages it originates.
-
A random, asymmetric key pair per participant, generated just before their registration.
- The private key is used to sign the participant’s messages.
- The public key is made available in the participant profile.
-
The Citizen Card authentication key pair.
- Its private component should be used to sign a participant’s registration message, which should include the certificate of the key pair mentioned above.
-
A random, symmetric key per participant and SA, generated before encrypting the deck and stored until being publicly disclosed.
Implementation details
Encryption algorithms
Since each number in the deck must be individually encrypted, and shuffled afterwards, it is not suitable to use stream ciphers. Use instead block ciphers. Furthermore, do not use padding (PKCS#5 or PKCS#7), as a single block of the cipher is more than enough to store a small integer number. For simplicity sake, all the entities that encrypt and decrypt the deck can use the exact same algorithm.
If you do not follow this rule, the size of the deck will grow rapidly after each encryption, as each number will result in a one block (the first) or the existing blocks plus an additional block (all the other participants).
Signature algorithms
The Citizen Card can only perform RSA signatures. However, the other signatures performed by the caller or the participants can use RSA, DSA (Digital Signature Algorithm) or ECDSA (Elliptic Curve Digital Signature Algorithms). In this last case, and for simplicity sake, you can use a single algorithm for everybody.
On the use of the Citizen Card
You should allow a participant to enter a shuffling process without using a Citizen Card. Thus, using the Citizen Card is an option when entering a shuffling process. When the Citizen Card is not used, the participant name is the one provided manually by a user.
Storage
Because all participants are present when the shuffling is taking place, the SA does not need to store any data. If it forwards all actions to other participants, it only needs to temporarily (in memory) store participants registration data and the action log.
A basic protocol needs to be implemented to support retrieval of this
information (````get_user_list, get_audit_log```)
Project delivery
Delivery should consist of a git repository, two main folders and a file:
proj1- containing the insecure implementation of the process described.insecure_app: insecure and vulnerable application.secure_app: insecure application with vulnerabilities fixed.analysis: contains the analysis of the vulnerabilities, including the demonstration, identification of the CWE, reasoning for the CVSS score and fixes applied.
proj2- containing the secure implementation of the process described.participant: contains the participant code, including instructions to run it.SA: containing the code of the shuffling area, including instructions to run it.report: contains the project description (keys, messages, process classes, etc…). An Markdown file may be enough.
README.md: contains information about the author and which projects are to be considered.
Students can deliver one or two projects, and should expect a live defense of the submissions.
Projects will be graded according to the logical implementation, the implementation of the code that implements the authentication and the protection of the related information, and the documentation produced.
The projects are expected to be authored by the students enrolled in the course. The use of existing code snippets, applications, or any other external functional element without proper acknowledgement is strictly forbidden. Themes and python/php/javascript libraries can be used, as long as the vulnerabilities are created by the students. If any content lacking proper acknowledgment is found in other sources, the current rules regarding plagiarism will be followed.