CS5430 System Security - Spring 2012 Project

CS5430 Project: Spring 2012

This semester you will build a secure social networking system. This document gives an overview of the project. Further details about each phase -- as it is announced -- will be linked to the the items just below.

Phase 0: Group formation. Form a group of at most 4 students. Click here for detailed info about this phase.
Phase 1: Requirements and Security Specification. Propose functionality and specify sensible security properties for your system. Click here for detailed info about this phase.
Phase 2: Baseline System Implementation. Build a Social Network Server and a Client GUI that together implement the functionality proposed in Phase 1. Ignore security properties for this phase. Click here for detailed info about this phase.
Phase 3: Authentication. Implement a means for users running the Client GUI to be authenticated to the Social Network Server. Click here for detailed info about this phase.
Phase 4: Authorization. Add mechanism so that each user can (i) specify an authorization policy (as initially specified in Phase 1) and (ii) have that policy be enforced. Click here for detailed info about this phase.

Required Functionality and System Components

A social-networking system allows a community of users to share content. The details of what and how content is shared typically differ from one system to another, reflecting the needs and values of some intended user community. All social-networking systems do seem to have certain things in common, though.

Users access the system either to upload or to read content postings on some posting board(s). The post operation allows a user to upload a content posting; the view operation allows a user to read some (perhaps specified subset of) content postings that have previously been uploaded by users executing post operations.
There may be multiple posting boards, with each posting board possibly sub-divided into regions. Each posting board has one user designated as owner. The owner of a posting board is, implicitly the owner of all regions implemented by that posting board.
Means exist for a pair of users to become friends for a given posting board region, set of regions, or set of posting boards. Authorization for a user U to view or post content on a posting board may depend only on the identity of the owner O of that posting board, the friends of O, the friends of U, and (possibly, even) their friends, etc. (Note, users related according to the mathematical relation we call "friends" need not know each other, like each other, etc -- the "friends" relation simply is the source of any and all information that may be used for authorization.)

This defines a rather large design space. Choices left open include the following (along with others).

How many regions can a user own?
How is the friends relation interpreted when deciding authorization for view or post. Is the friends relation symmetric? Transitive? Is there a separate friends relation for each owner? Each posting board? Each region?
What actions must be undertaken by whom in order for an owner and another user to become friends? Must the owner consent? Must the user consent? Must other "current" friends consent? Must friends of friends consent?
How does a user specify what posting board(s) are accessed when a post operation or a view operation is invoked? Who decides---the user invoking the operation or the posting board owner or both? How much flexibility is there for making this selection? When is the selection made---at the time the user invokes the operation or earlier?

For Phase 1, you must decide on a social-networking system to build. We suggest that you identify a specific, well-defined community for your system to serve. Then, contemplate features and design choices that would be most useful for this community.

Requirements on System Components and Structure. Your social-networking system must exhibit the following structure or else it could be difficult to complete all of the project phases: There is a Client GUI that runs as a process and communicates with a Social Network Server that runs as another. Although the components of your system should be implemented as two processes running on separate computers, we suggest developing the system with both processes sharing a single computer.

For the Social Network Server, you may assume it executes on hardware that

supports a file system or database system stored on disk or on some other form of persistent storage, and
is located in a physically secured machine room that can be reached only by trustworthy system operators.

The Social Network Server is responsible for (at least) the following functionality:

storing content postings for all users,
monitoring a well-known TCP/IP port and handling requests originated by instances of a Client GUI component.

For the Client GUI component, you may assume that it executes on hardware that

does not have a disk or other form of persistent storage, and
might be located anywhere and/or being used by anyone.

The Client GUI is responsible for (at least) the following functionality.

allowing a new user to be added or an existing user to terminate its participation,
allowing a user to post or view content postings,
allowing a user to initiate or consummate changes to a friends relation, and
allowing a user to choose among authorization policies supported by the system.

This project is part of a class on computer security, so we make a few simplifying assumptions that will help focus attention on the interesting matters.

Content postings comprise a header and a body, both of which are unformatted sequences of text characters. Other forms of content are not supported.
The aesthetic aspects of all user and operator interfaces is irrelevant.

Extra Credit. Include functionality that allows any user to upload Java classes and execute methods at the Social Network Server, as follows.

Extend the Client GUI so that any user U can (i) input a file name for a local file containing a Java class, (ii) cause that Java class to be transferred to the Social Network Server and stored in persistent storage associated with U, and (iii) thereafter U can use the Client GUI to request that a particular method in that class be executed under the authority of that user.
Extend the Social Network Server to provide an interface comprising methods for manipulating and reading posting boards and other data structures. Such methods are executed under the authority of the requestor. The up-loaded user-provided classes invoke these methods to implement new functionality.

This extra credit functionality is particularly challenging, because you must defend against objects that untrustworthy users design and deploy hoping to corrupt the Social Network Server or to circumvent the authorization it enforces. Projects will receive grade deductions if vulnerabilities are created by code you add for supporting the Extra Credit functionality. Know your limits---the grading scheme will punish those who do not. (Discretion is the better part of valor.)

General Technical Matters

Implement your system using code that can be found in the standard Java distribution. However, to level the playing field and to ensure that you spend your energies in ways that will contribute to your education, we impose the following additional ground rules about use of code that isn't written by members of your group.

Cryptographic Code. The following Java implementations of cryptographic functionality may be used in building your system:

Crypto API's in the java.security and javax.crypto packages (built-in or self-written providers only).
Public Key Infrastructure in the java.security package and its subpackages, including the PKI tools for key management.
java.lang.SecurityManager for access controls
java.security.SecureClassLoader for implementing the Extra Credit (only).

The following Java implementations of cryptographic functionality (e.g, key exchange and authentication) may not be used because what they offer is too close to functionality we are expecting you to study.

Authentication and Authorization APIs (JAAS) in the javax.security.auth package and subpackages.
Secure Communication APIs (JSSE) in the javax.net.ssl and javax.security.sasl packages.
Any of the com.sun.security subpackages.

Database. A database might be useful for storing content postings (though this is by no means required). Feel free to use a MySQL database, with the JDBC package to interface.

Keys and Secrets. Set-up assumptions for cryptographic keys and other secrets, because they are assumptions, can often be turned into exploitable vulnerabilities. Therefore, your system must satisfy the following restrictions.

The source code for Client GUI may contain a single public key but may not contain any secrets (i.e., private keys, shared keys, or passwords). However, the procedure for starting the Social Network Server may require that the operator enter a secret (perhaps, even, a very long secret).
The source code for the Social Network Server may contain a single public key but may not contain any secrets (i.e., private keys, shared keys, or passwords).
The persistent storage (file system and database system) managed by the Social Network Server may not store any secrets (i.e., content postings private keys, shared keys, or passwords) in the clear.

Administrative Matters

Working in Groups. Projects are built by groups of at most 4 students. Working in groups offers various benefits:

Discussing ideas with others is a powerful tool that far offsets the additional time required for coordination within a small group.
Working in a group affords the opportunity for parallel development activities (although all members of your group are ultimately responsible for understanding all aspects of the system you build).
Working in a group helps hone skills needed to be effective in the workplace (where groups are the norm) and impresses potential employers.

Groups of size 2 or 3 have worked best for CS5430 projects. Groups larger than 3 often have difficulty coordinating among members---for example, finding times that all members can meet. No single-person group has ever delivered a CS5430 project that received a reasonable grade. (Maybe you will be the exception, but ...).

MEng Project Option. MEng students may use their CS5430 project as the basis for the required MEng project. If this is your intention, then:

All group members must be MEng students who are electing to use the project in this manner.
Your group must implement the "extra credit" functionality discussed above.
You must provide a written "project report" at the end of the project. This report should describe the functional requirements for your system, security properties being enforced (along with the threat(s) you are assuming), and describe the approaches you employ for authentication and for authorization. Besides this synthesis of Phases 1 - 4, your report should give instructions for both installation and use of your system. Such a report typically runs 15-30 pages.