CS5430 Project: Spring 2009

CS5430 students are expected to participate in a group project to build an application that has non-trivial security content. Each group this semester will be implementing an electronic marketplace. This document outlines what is expected and offers some advice.

An Electronic Marketplace

Connecting buyers with sellers facilitates commerce. Once upon a time, such transactions were facilitated by having a well known venue where sellers would congregate and buyers could go to make purchases. In modern times, physical locations like the local auction house or a nation's stock market are being replaced by electronic marketplaces. eBay and NASDAQ are examples.

An electronic marketplace provides operations their clients can trust to facilitate buying and selling. Whether it is antiques or financial instruments (e.g., stocks, bonds, and even collateralized debt obligations), an electronic marketplace must support the following kinds of operations:

Post an item for sale:

A seller employs this operation to list some item for sale. The seller provides information about the nature of the offering (e.g., "an antique half-hull sailboat model" or "100 shares GM common stock") and information about the minimum price (called the reserve price) that the seller is willing to accept.

Determine what items are for sale:

The user of the electronic marketplace must be able to ascertain what items are offered for sale, perhaps also with information about prices. The information returned for each item might only be a subset of what the electronic marketplace knows about the item. For example, in some settings, such as a financial market, the identity of the buyer and seller might be kept confidential.

Make an offer to purchase an item:

A buyer invokes this operation to indicate that buyers willingness to purchase some specified item or some item satisfying specified criteria. The offer might be for an item already listed as being for sale (e.g., an antique) or the offer might be in anticipation that some suitable item will later be offered for sale (e.g., some stock). In some settings, the price being offered might be specified by the buyer; in other settings, a range might be specified; and in yet others, the electronic marketplace might never learn how much a buyer is willing to pay.

Besides implementing a protocol for matching buyers and sellers, your electronic marketplace must be a networked system that includes:

• A buyer's app, which is an application program that supports a GUI, runs on a buyer's workstation, and uses a network to communicate with the other subsystems that are part of the electronic market.

• A seller's app, which is an application program that supports a GUI, runs on a seller's workstation, and uses a network to communicate with the other subsystems that are part of the electronic market.

• One or more backend servers, which store information about items for sale, offers to purchase an item, etc.

In some markets, item availability and/or prices are highly volatile. The stock market is an example. Therefore, electronic markets sometimes support programmed trading. Buyers and sellers upload programs---which we will call trading agents---to the electronic marketplace. And the electronic marketplace provides an interface to execute trading agents, allowing them to monitor prices, update reserve prices, and make and withdraw purchase offers. In short, a trading agent "speaks for" (represents) a buyer or seller.

To support trading agents in an electronic marketplace is an ambitious undertaking, so don't attempt this unless you want a challenge. You would define a programming language that buyers and sellers can use for implementing their trading agents; this language might be general purpose (e.g., x86 assembly, C, Java, Perl, Python, or JavaScript) or special purpose (e.g., some interpreted language of your own design). And you would add suitable security features to the electronic marketplace. To wit, the existence of trading agents would mean the electronic marketplace would somehow have to be protected from

• an attacker's trading agent that attempts to cheat or disrupt operation of the electronic market, and

• one trading agent from accessing (and analyzing) another in order to anticipate or alter a competitor's strategy.

The Project

As should now be clear, there is considerable latitude in what functionality an electronic marketplace supports and in how that functionality is implemented. Not surprisingly, for a CS5430 project, we are most interested in having you explore functionality that involves interesting security properties or that leads to interesting instantiations of security principles or deployment of security technology. Part of your project grade will, therefore, depend on what functionality you support, the design you create, and the security technology you deploy.

• GUI. Build a serviceable GUI, but don't invest heavily in making it flashy. In evaluating your work, the graders' concern will be whether the GUI makes it difficult for users to do things they don't intend or they would regret.

• Auctions. There are numerous options here---English auctions, Dutch auctions, Sealed first-price auctions, Vickrey auctions, all-pay auctions, etc. Some of the more complicated auctions require that interesting security properties be enforced by the electronic marketplace, so implementing them could be challenging and instructive. But supporting a complicated auction that does not require special security guarantees will not impress the graders.

• Matching Criteria. An electronic marketplace can provide great value by supporting rich search functionality so that a buyer can efficiently find items of interest. Supporting such searches is largely orthogonal to the security matters that concern us in CS5430. Therefore, this is not a good place to invest your time or energy.

• Backend Server Implementation. Do a respectable job implementing a single centralized server and you will get a respectable grade. Only after you get this running, should you contemplate building a backend service with multiple servers or a peer-to-peer organization. Support for trading agents will impress the graders more than support for multiple servers or a peer-to-peer organization.

• Payment. Some electronic marketplaces support payment by communicating directly with a credit card payment system, PayPal, etc. You are not likely to have the time to do this well, so we recommend that you do not attempt to provide such functionality in your system.

Deliverables for Each Phase

Phase I: Group Definition [Due 2/2 (10:00am)]

This phase is easy. Form a group of 1 to 5 CS5430 students, and submit a typeset document (.doc or .txt are best) that includes the following information.

• A name for the system to be built.
• Members of the project group, giving a name and Cornell net id for each.

You may consult only with these group members and the course staff in building your project.

Profit from our past experience. Groups of size 3 seem to work best. Groups smaller than 3 almost always get lower grades on the project; groups larger than 3 sometimes have difficulty finding times that all participants can meet. One-person groups almost never finish and thus usually receive a terrible grade on the project. Why should this be so?

• Discussing ideas with others is a powerful tool that far offsets the additional time required for coordination within a group.
• Working in a group affords the opportunity for parallel development activities (although ultimately all members of your group are responsible for understanding all aspects of the system you build).

Savvy students also appreciate that after graduation you will likely work in a group. Thus, working in a group in CS5430 helps hone skills needed to be effective in the workplace and also impresses potential employers.

MEng project option. MEng students can use their CS5430 project as the basis for the required MEng project. If this is your intention, then your group must all be MEng students who are all electing to use the project in this manner. Your group is then not only expected to satisfy the project requirements outlined below but is also be expected to:

1. Implement some additional functionality, as agreed upon between your group and the course staff.
2. Provide a written "project report" for the entire project. This report should document the problem solved, the design alternatives, a rationale for design selected, the implementation, the testing strategy employed, and give instructions for both installation and use.

Plan to start these additional tasks after this semester ends and complete them before the Fall 2009 semester commences.

Phase II: Functional and Security Properties [Due 2/18 (10:00am)]

The description given above outlines functions the system must have and mentions additional features it might have. Thus, there is considerable latitude in what you might build as an electronic marketplace. The description given above also says little about security properties that such a system must enforce. Phase II of the CS5430 project is the point where your group pins those things down. So, for this phase, you should decide what kind of electronic marketplace you plan to build and describe that in a document (.doc is best) of at most 7 sides (11 point type, 8.5 x 11 inch pages).

Your Phase II submission should contain:

• The name of your group, along with the name and Cornell net id for each member of the group.

• Functions and features you intend to implement in your system. Your design, implementation, and presentation/demo will be evaluated based on the planned functionality you announce here.

• Security properties that support the planned functionality. Various aspects of your planned functionality will make sense only if operations cannot be undermined. What security guarantees do you intend your system to offer? Classify these security guarantees in terms of confidentiality, integrity, and availability properties. What threats and kinds of attacks will your system resist? How can your system convince a buyer and seller that their transaction was conducted in accordance with the promised kind of auction? What, if any, notions of "fairness" will be supported for the market that your electronic marketplace creates?

The document you submit should resemble what might be provided to students when assigning a course project in a (senior-level) undergraduate programming class. Thus, the document should describe the class of items (e.g., stocks vs antiques vs real estate) that can be sold using your electronic marketplace, how the system would be used by sellers and buyers, what its architecture is (centralized server versus peer to peer, etc), what functional and security properties it will satisfy, what assumptions are being made about the deployment environment and about clients, and what threats are of concern.

We will evaluate your Phase II submission against the following criteria.

• Whether the document you submit is easy to understand and clearly written. (Correct English style and usage counts here, just as it does in the real world.)

• Whether the planned functionality seems sensible given the proposed purpose (i.e., class of items being sold) of your electronic marketplace. For example, support for trading agents only makes sense where prices are subject to rapid fluctuations (such as in financial markets). As another example, a system for buying and selling stock should allow a client to buy only 50 shares of a 100 share package that is being offered for sale. And as a final example, antiques auctions frequently allow a buyer to make a bid that applies to each element in a set of equivalent objects but then only purchase a few; other bidders are then given the opportunity to purchase the remaining objects (at that price or through another auction). It is wise to use an existing market as the starting point for defining the planned functionality of your electronic marketplace.

• Whether the security properties to be enforced are sensible for the planned functionality and system architecture.

• Whether the threats of concern and their capabilities are described clearly.

Phase III: System Design and Rationale [Due 3/11 (10:00am)]

Extend the document you submitted for Phase II---adding at most 7 sides---and outline the design for your system. Devote more space to what you think are the tricky parts, explaining what the pitfalls are and how you will avoid them. Give citations for protocols you borrow; give specifications for protocols you invent (where the specification details the sequences of messages exchanged); give descriptions of all important program interfaces (at a level of detail suitable to convince the reader that your design is sensible). It is better to borrow (and perhaps modify) a protocol or idea from the literature (which therefore is likely to be correct) than to invent one yourself.

The augmented document should also describe the programming language(s) you will use, what components you plan to build from scratch, what off-the-shelf components you plan to modify, and what off-the-shelf components you plan to use as is. Detail the ways in which off-the-shelf components are being trusted.

We will evaluate your Phase II submission against the following criteria.

• Whether the documents are easy to understand and clearly written. (The document should be written at a suitable level to be understood by (say) a senior undergraduate computer science major.)

• Whether the design covers all of the planned functionality announced in your Phase II submission.

• Whether the design enforces the promised security properties (and any others that ought to hold).

• Whether vulnerabilities are present in the design.

• Whether a suitable choice of tools being made.

Phase IV: Implement and Present [Due 4/27 (10:00am)]

Sign-up. Decide where (CSUG or MEng Lab) you want to conduct your final presentation and when. Then, schedule a Presentation/Demo meeting slot for the week of April 27. Use the sign-up sheet posted on the door of Upson 4115 to schedule your meeting.

Preparing for the Presentation/Demo Meeting. The Presentation/Demo meeting encompasses an hour, and will be structured as follows.

• An uninterrupted presentation that one or more members of your group give using Powerpoint slides [10 minutes]. Plan to display the slides using the same computer screen(s) that you use later to demo your system. Rehearse the presentation well---the time limit will be strictly enforced, and the quality of your presentation counts.

  Slides should contain short telegraphic phrases, figures, algorithms (in an easily understood pseudocode), and performance numbers. Use the Powerpoint "speakers notes" feature to amplify what appears on a slide. The "speakers notes" should be prose (i.e., sentences and paragraphs) that is complete enough so that anyone can read them and understand the crux of the slide they accompany. What is said when presenting a slide and what is written in the "speakers notes" is unlikely to be the same---spoken language is less efficient and therefore requires repetition that written notes don't.

  Your presentation should: (i) remind us what your system does, (ii) discuss the "security content" of your project, (iii) describe what (if any) design or implementation innovations were required to complete the project, (iv) explain why your design is a good one, and (v) explain why we should believe that your system satisfies its stated security properties.

• A demo of your system [8 minutes]. Make sure you have an easy way to transition from the Powerpoint presentation to the demo itself. This demo should show that your system works and should convey a sense of what functionality your system implements. A fancy GUI will not impress us; a robust system will impress us (since lack of robustness implies the presence of code vulnerabilities).

• A question/answer session [10 minutes]. We ask; you answer. Anything about your system---functionality, design choices, related work---is fair game. Plan to convince us that you are truly the experts on subject matter concerning your system. Questions may be directed to any member of the group.

• Evaluation of the source code with a TA [30 minutes]. Be prepared to help a TA take a "guided tour" of portions of your code that interest him. Code that you have written should be clearly identified so that it is quickly located and cannot be confused with other code that is used in your system. We will look over excerpts of your code to see whether your project is based on a clean design and was implemented using good software engineering practices (including secure coding practices and useful source code comments). Projects containing code vulnerabilities will be severely penalized.

What to Submit. You need not submit anything until the start of your Presentation/Demo meeting. At that time, you should provide us with:

• Two printed (either black and white or color is fine) copies of your Powerpoint presentation, where each page contains a slide image and associated speakers notes. (This is called "notes pages" on the Powerpoint Print menu.)
• A CD containing
  • the ppt file used for your Presentation/Demo meeting and
  • all the code and other files for your system and demo.

Grading for Phase IV. Your grade for Phase IV will be computed as follows:

• presentation content (slides and "speakers notes"), delivery, and adhering to time limit [15%],
• demo---does the demo and underlying system work [10%] and does it illustrate the security functionality [15%],
• performance during the question/answer session [10%],
• code and design review [20%],
• assurance argument, including a test plan and evidence that the test plan was successfully performed [5%], and an explanation of how the system meets each of the security requirements enumerated in Phase II [5%],
• how difficult an undertaking was this project [10%], and
• other subjective factors about project goals, implementation, and presentation [10%]