CS453, HW3

CS453, HW3: Secret Message Drop

You may work alone or in groups of two on this assignment.
Due: Monday, July 27, 8 pm. (10% penalty per day, up to 2 days)
Submit to the Collab.

In this assignment, you'll create a small system made up of a set of webpages that will include the use of the following technologies:
HTML forms, JavaScript, CSS, PHP, cookies, processing form data with PHP, files in PHP, encryption algorithms

These pages and code will form a system where a person, say Morgan, can leave a message on the webserver for another person, say Alex. This message will be encrypted on the server so that it can only be read by Alex when the access the server through a webpage that shows what secret messages have been left for Alex. (There can only be one message from the "sender", Morgan, but Alex may have messages from many senders.)

Note: This is a "toy problem" in that the system you're likely to build is probably not going to be effective in how it maintains security. That's OK. You'll be asked to analyze what the security issues are here in a write-up. The homework's goal is to get some practice with the technologies and think about how encryption is used.

The system will offer a web-user the following capabilities. There may be a separate web-page for each of these, but if your product does it differently, no penalty as long as you provide the capabilities. (In fact, what's presented here are general principles of what we want built. If your system varies somewhat, no problem. Be sure to document the differences in the write-up. Check with the instructor if you're not sure if your variation will be OK.)
Handling these basic capabilities will earn you up to 95% (an A according to our scale). There are two optional capabilities, each worth 5% extra.

1) Create Keys and Register:

A user will enter a user-ID (please use your UVa email ID), and a PHP script running on the server will generate public and private keys to be used for this system. (See note on PHP encryption below.) The public key will be stored for the given user on the server. The user-id and perhaps also the public key should be stored on a cookie on the user's machine. (You decide if you need to store the public-key.) Once the public-key/user-id pair is stored on the server, that user is "registered" in the system.

Optional: You may choose to give the user the chance to store his or her private key in a cookie on the local machine.

2) List and Read Messages:

A user views a page that shows him or her a list of all messages left for that user (and not messages for other users). It will show the message-sender's user-id only. The user can pick one of these messages, and he or she will then view the decrypted message in the web-browser. In order for the message to be decrypted, the user's private-key must be made available. You could have the user enter this into a form, or...

Optional: If the private-key is stored in a cookie it can be obtained that way.

Optional: See the digital signature option discussed later. If you do this, the user will also get some indication that verifies the message really did come from that sender.

3) Leave Message:

A user visits a page that lets him or her leave a message for a particular user. The system may show the list of registered users, or it may validate that the user chosen is already registered with the system. A short message will be typed in by the user, and then stored in encrypted form on the server, in a way that only the recipient can decrypt it. If the sender's user-id is not stored in a cookie on the current machine, prompt for the user id.

Optional: See the digital signature option discussed later. If you do this, you'll have to create a digital signature here and also send it to the server to be stored.

4) Optional capability: Digital Signatures

Doing this is worth 5% additional points.

When leaving a message, a digital signature and/or hash is created based on information about the sender. This is stored on the server, and used when the recipient reads the decrypted message and shows something that assures the recipient that it really came from the sender and hasn't been tampered with.

5) Optional capability: Using Symmetric Key Encryption

Doing the following is worth 5% additional points.

Symmetric key encryption can be combined with the use of public key encryption described here to improve security. In general, this might mean passing around a secret key, and perhaps also doing decryption in the client (e.g. perhaps with some decryption algorithm in JavaScript). Design and describe your system for combining these two techniques and implement them in your system. (You're allowed to create a second version derived from your basic system that does this and turn in both.)

What's Stored Where?

On the server, you may use a database if you want to and know how. (No extra credit for this.) A simple file organization will do the trick, and you'll have to learn how to process files using PHP. For example, you could do this.

One file holds a list of user-id/public-key pairs.
Each message has a name format that let's you easily see who sent it to whom, e.g. msg-morgan-alex.
If you are doing digital signatures, you can put that into a file named by some convention you choose, e.g. msg-morgan-alex.sig

You may discover you need to store other things on the server.

Some information goes into cookies, even though there may be security issues here. The user's user-id will always be stored. The public-key can be stored in a cookie if you think this is needed. The user's private-key can be stored in a cookie, if you wish. (In your write-up, you'll discuss what you stored in cookies, why, and any risks.

Encryption in PHP (and JavaScript)

Don't write your own encryption algorithms (or hashing algorithms or whatever). Find them on the Web. Below are two links to code out there that you can use to generate keys, encrypt and decrypt for RSA public-key encryption. You may find better choices.

You won't need to do encryption in JavaScript unless you're doing one of the optional items. RSA encryption is generally not practical in JavaScript (but you may find code). There are symmetric key encryption implementations for JavaScript out there, and for example Blowfish may be a good choice.

Design Report:

You'll zip up all your files and also include a design report. In this report you will give an overall description of your system's design that we can use when running your system. This report must include:

A link to an installed version of your system on a webserver.
A description of how your system varies from this basic overview. (It's OK if it does. Just explain in high-level terms.)
An analysis of how secure or vulnerable your system really is.
Sources for code libraries you used, and any other code that helped you in building your system.
A discussion of the strategies/process you used for encryption and related activities for all operations (e.g. leaving secret messages, viewing secret messages, and handling digital signatures).

Grading Critieria:

Coming soon!