CSE509 Spring 2006. Computer Security
Note: If you would like to do a different class project, feel free to
come discuss you project ideas with me.
Phase I: A Secure File Server
Write a secure remote file server that supports the following
- Each message in the protocol is terminated by the C characters "\r\n".
- USERNAME is an ASCII string.
- N, e, C, R, and y are represented as integers in ASCII in base 16 during transmission.
- K is transmitted as a hex dump of its bytes, i.e. convert each byte into two hex characters and transmit them.
- N and e are represented as integers in ASCII in base 16 in the user's config file, .sfs.
- K is represented as a hex dump in the user's .sfs file
- The encrypted file is tansferred as raw bytes.
- The ", " are literals in the protocol
- PASSWD is an ASCII string up to 16 bytes.
- PASSWD is padded to 16 bytes by appending 0 bytes when used as a key in AES.
- d is represented as an integer in ASCII in base 16 during encryption via AES-CBC.
- d is padded to a multiple of 16 bytes by prepending ASCII "0"s
- C is represented as an integer in ASCII in base 16 during computation of message R.
- FILENAME is a string, up to 240 bytes, in ASCII, excluding the terminating NULL character, in the computation of message R.
- The "(", ", ", and ")" are literals in the computation of message R
- Whenever the bytes of an ASCII string are re-interpreted as an integer, use big-endian byte order.
- S is generated randomly for each request
- S is represented as an integer in ASCII in base 16 during computation of message y, without the terminating NULL character.
- The server uses PKCS5 padding when encrypting the file using AES/CBC.
- The server closes the connection after sending the last byte of Z.
- The server listens for connection requests on port 5096.
Suppose (small values are used for convenience, values are not guaranteed to be correct or even make sense)
- USERNAME = "rob"
- N = 41436197399383046674769
- e = 31142868322202020882931
- K = 1234567890123456 = AES-CBC("hehe\0\0\0\0\0\0\0\0\0\0\0\0", "26841096087855436504571")
- d = 26841096087855436504571
- C = 0123456789012345
- R = 56789123
- PASSWD = "hehe"
- FILENAME = "foo/bar"
- S = 4235546
- Client -> Server "rob\r\n"
- Server -> Client "41436197399383046674769, 31142868322202020882931, 1234567890123456, 0123456789012345\r\n"
- Client computes
m = AES-CBC^-1("hehe\0\0\0\0\0\0\0\0\0\0\0\0", 1234567890123456)
(if things worked, then m = "26841096087855436504571")
d = (parse m to get integer)
t = "(0123456789012345, foo/bar)"
x = (interpret bytes of t as an integer, big-endian)
R = x^d mod N
- Client -> Server "56789123\r\n"
- Server performs similar computation
- Server computes
S = random(128-bits)
t = "4235546"
x = (interpret bytes of t as an integer, big-endian)
y = x^e mod N
Z = AES-CBC(S, FILE)
- Server -> Client "y, Z"
You may work in teams of 2. You must not share code or ideas with
other teams. You are encouraged to test your programs with programs
written by other teams to check that you adhere to the specification
(i.e. you can test whether your client can work with another team's
server and vice-versa). You should implement 3 programs:
The K-generator program should take as input a file containing N,
e, and d, and a password read from the user, and generate a .sfs file.
K-generator does not need to generate N,e,d triples. As a test input,
you may use (N, e, d, one per line):
You do not need to implement AES, or CBC mode of AES. You do not
need to implement modular multiplication, but you should implement
your own modular exponentiation. You are encouraged to use existing
libraries for AES, CBC mode, and basic modular arithmetic of big
integers (see Java BigInt class or the GNU MP Bignum library).
For testing purposes, your code should run on the departmental machine
You should also write a 1-page description of the security goals this
server should maintain.
Your team will be given the servers written by 2 other teams. Find as
many security bugs as you can in their implementation. Security bugs
are not limited to simple programming bugs like buffer overflows. Any
attack you can develop that violates a security goal of the server and
that the server could be modified to prevent is acceptable.
You should analyze each project for all the relevant security bugs
you can find. Note that there are bugs in the above protocol, and you
may write up a description of those bugs as a seperate report.
However, don't include protocol bugs in your report on the
implementation. You should look for things like buffer overflows,
format string bugs, timing attacks, etc. For each bug you find,
please include a 1 paragraph description. Your description should
If you find several similar bugs in a project, then you can combine
those into one paragraph. Describe one of the bugs as above, and add
a comment indicating that you think the rest are similar. If you
can't find any security holes in a project, then write a 1/2-1 page
report on your methodology for analyzing the project and your
conclusions about its security.
- The location of the bug in the source code (e.g. "server.c:1024")
- The nature of the bug (e.g. "stack overflow")
- An explanation for why you think it is exploitable (e.g. "The source of the strcpy is the filename provided by the user.")
- A description of input that could trigger the bug (e.g. "The attacker can send a long filename with embedded shell-code.")
- Any prerequisites for exploiting the bug (e.g. "The attacker must have
a valid account on the victim machine in order to get the filename decrypted correctly by the server.")
- The security goal that can be violated using this bug (e.g. "The attacker can gain root access on the server.")
- 4/4: Project status meeting
- 4/18: Server, client, and K-generator due
- 5/4: Code Analyses due