CS5432 Advanced System Security - Social Network Project - Spring 2021

You will implement a social network, where users upload content and/or read content posted by other users. You will decide the exact functionality and security guarantees. Your deliverable for this phase is to describe those choices. Changes to that proposal can still be made (without penalty, if accompanied by credible justifications) in the documentation you submit for the next phase. After that, however, failure to deliver a system that implements what you promise will affect your grade.

We require that your proposed social network system (i) authenticates users, (ii) provides a means to control which users have access to content, and (iii) provides a means to control whether non-users (including system administrators and law enforcement) have access to content that is in transit or being stored. Of course, a "real" system to support social networks would have fancy user interfaces and might use AI to better serve its users. But the focus of CS5432 is on computer security, so our evaluation criteria for your project will focus on computer security -- and you should, too.

Implementation. Use the programming language of your choice and the run-time environment provided by the software platform of your choice. However, functionality and assurance are both important for your system. So if you select a language (e.g., C or C++) that does not come with strong safety guarantees then plan to employ means (e.g., coding discipline, static analysis tools, testing) to mitigate the additional risks.

Users of a social network might be using different computers. And if your implementation employs a server, then it will be running on yet another computer. To simulate a distributed system, you may use (i) computers owned by people in your group and/or (ii) computers in the undergrad lab and/or (iii) a single computer hosting a separate process or virtual machine for each processor in the (simulated) distributed system. In all cases, use TCP/IP (or some extension) for communications. Shared files are prohibited (except at startup). Note, the system demo at the end of the semester will be performed using zoom, which allows sharing the screen of only one computer -- plan ahead!

Security Functionality. Your social network implementation should include the following elements concerned with computer security.

• Authentication of Users. Passwords are an obvious mechanism for implementing "something you know". Your system might also provide support to ensure that only "good" passwords are selected. To implement authentication based on "something you have", your system could require inserting a specific memory stick into a USB port. Two factor-authentication could be supported by requiring both. Computers that have fingerprint readers offer the potential to employ "something you are" for authentication (though the access to system services and/or I/O devices often is complex).

• Authorization for Content Access. A posting user may indicate a group of users that can read that item; a reading user may indicate which kinds of postings, if they exist, should be displayed. There are many different approaches for determining which user sees which posts. Use an existing system (e.g., twitter, facebook, and piazza) as a source of inspiration or design something completely different.

• Security for Postings. The confidentiality and integrity of postings must be protected. The means of enforcement is up to you.
  • Stored Postings. Postings stored on a computer or its disks could be protected by using existing operating system mechanisms for protecting memory and files. Encryption might be used in addition or instead, but keys then must be stored in a secure way. Some protection mechanisms will protect against certain or all acts by system operators; you might allow access to content by law enforcement (when a suitable warrant is produced) but not allow access to system operators; some protection mechanisms will protect access even if an attacker is executing a process on the server.

  • Postings in Transit. Cryptography is the obvious solution here. Use an existing standard (e.g., SSL) to reduce your work.

Various system architectures could be used. Pick one of these, or design your own.

• Peer to Peer Architecture. A peer-to-peer design would have clients communicating directly with other clients and would not employ a server. One challenge here is for a client to determine where each posting should be sent. Another challenge arises if clients are not executing all the time but correct system operation requires eventual delivery of postings to them.

• Web-based Architecture. Existing web browsers can be the clients and existing web servers can be the servers. Use of existing software (the browser and a scripting language at the backend web server) simplifies some implementation tasks (for those who are facile with web scripting languages) but also imposes limitations on security functionality.

• Client-Server Architecture. This is the most straightforward approach. A single backend server might communicate with the app that each user runs. Or multiple backend servers might be deployed, where (i) each handles a different partition of the set of posters, (ii) each handles a different partition of the set of readers, or (iii) servers are replicas and each handles all users.

Phase 1 Deliverable

The deliverable for this phase is a relatively short document that describes the system that your group will build. This document serves two purposes.

• It allows the course staff to check that what you plan to build is sufficiently (but not overly) ambitious for a course project. Where there are obvious problems, we will ask questions or make suggestions about how to proceed. If there are severe problems then we may invite you to submit a revised document, which we will also review.

• It defines what you will be building and establishes the baseline against which your system will be evaluated. You will not receive a higher grade on the project for implementing more functionality than is specified in this document, but you could receive course "extra credit".

Your Phase 1 deliverable should be submitted to CMS as a .pdf. Use 10 point font or larger, "single" line spacing, and at least 1 inch margins. The entire document should be at most 3 pages (single-sided) and likely will be shorter.

Structure your document as follows.

Title: A short descriptive title for your system. (A cute title that is not descriptive will not receive full credit.)

Group: The list of group members. Give the full name and netid for each.

Implementation Target: What programming language(s) and operating system platforms will be used. How will assurance in the resulting system be established?

System Details:

Authentication of People: Description of how users and others will be authenticated.

Authorization of Content Access: Description of how users specify which other users are eligible to see a given post. Can these specifications be changed and when do those changes take effect? Can a user determine which other users could see posts? Can a user determine which other user's posts it will see? In short, what is the authorization model being implemented.

Postings Protection: Description of how the system will protect the confidentiality and integrity of postings that are being stored or are in transit. Discuss any protections (or lack thereof) for defense against operators and/or to facilitate law enforcement access.

System Architecture: High level description of the system architecture. Where do clients reside? Where do server(s) reside?

Phase 1 Grading Criteria

Your Phase 1 submission will be evaluated against criteria listed below.

• Whether the document you submit contains the required sections.

• Whether each section contains the required content and the proposed system is supporting the required security functionality.

• Whether a reasonable implementation target been selected.