Introduction
Get（）Updata（）Quit（）
，（1，2），
，SIGTERMwhiteboard.all，
Requirement
CMPUT 379, Assignment 2, Winter 2017
(Sockets, Synchronization, Message Passing, Encryption)
Objective
You are asked to implement a “whiteboard” server and its accompanying client.
Developing the solution requires that you get familiar with programming using
the socket API, which will be covered in the labs. The specifications of the
assignment include a specification of the protocol between client and server and
a minimum of client-side and server-side behavior/interaction.
Client-Server Protocol Specification
Initial Handshake
Upon connection of a client to the server, the server responds by sending the
following response in ASCII (\n denotes the ASCII newline character):
CMPUT379 Whiteboard Server v0\n
followed by the number of entries in the whiteboard. For example, the complete
response could look like this:
CMPUT379 Whiteboard Server v0\n38\n
Note that between a newline and the beginning of the next output “line” there
is no whitespace of any sort. At all times, every request and response sent by
client or server is to be terminated by a newline as in the above example.
A server supports a certain maximum number of whiteboard entries (in the case
of the example 38). The whiteboard entries are numbered, starting from 1.
Whiteboard Messages
A client can send a query such as:
?12\n
meaning that the client wants to receive the 12-th entry of the whiteboard (the
? is the ASCII question mark character). The response from the server follows
the syntax as in this example:
!12p30\nthisisaresponsetodemothelength\n
1
where the first character is the exclamation mark, the 12 is the entry being sent.
The p is explained later. The next is the number of bytes in the entry sent (count
the characters of thisisaresponsetodemothelength – they are exactly thirty).
Note that if the entry is currently empty, then the response would have been:
!12p0\n\n
A client can update a whiteboard entry by sending a message such as:
@12p16\nthisisawritetest\n
following the same conventions as the entry query message. Note that the
previous contents of the entry, 12 in this example, is replaced completely. The
server responds with
!12e0\n\n
to indicate success of the update. Syntactically, this is an “error” message of
zero content length – our convention will be that a zero-length content error
message is in fact a success confirmation! (Got it? :-)
Some meaningful error responses are however possible. For example, there is
a chance that the query/update cannot take place. For example, if you try
to query/update an entry with a number larger than the number of entries
supported by the server (say entry 47 for our example), the server responds with
an error message:
!47e14\nNo such entry!\n
(Yes, you should not have sent the query in the first place because you knew
when you connected that the server in this example supported up to 38 entries.
However you are supposed to prepare the server in a “defensive” way to deal
with such hicups and report the error as shown.) You have the freedom to define
the textual representation of error messages that you see fit as long as they are
adequately informative.
Finally, note that a client can “clean” an entry using an empty update command,
e.g.:
@12p0\n\n
Upon clean server initialization, all entries are clean.
Encrypted Entries
The p character used after the item number in the previous examples indicates
that the corresponding entry is in plaintext and is being sent as such. A client
can enter encrypted (using the c designator) entries in the whiteboard. In other
words, an entry can be either an encrypted or a plaintext entry. One could
query:
2
?12\n
to which the response could be
!12c128\nGA0D3n8AMWmUBYFxahOi……phJ4qeSJn1rOxgZm9yIHRoZQ==\n
(shortened for the sake of brevity – there would have to be exactly 128 characters
between the two \n ). Note that if an entry is empty (unoccupied) it is to be
reported as unencrypted, i.e., as e.g. !12p0\n\n . There is nothing special, as
far as the server is concerned, when dealing with updates, i.e., you can update
an encrypted entry to a non-encrypted one and vice versa. The only thing the
server needs to additionally keep track of, is to make a note whether an entry is
currently a p or c entry.
A client that receives an encrypted message has to extact the encrypted message,
and try out to decrypt it using the keys in its possession (more details about
the keys of the client in the interface section). A client can tell if it has used the
right key for the decryption if the decryption function did not return an error
status and if the output from the decryption follows the format:
CMPUT379 Whiteboard Encrypted v0\n…the plaintext we encrypted…
In a similar manner, a client that wishes to enter/update an entry with an
encrypted message should send something like:
@12c128\nGA0D3n8AMWmUBYFxahOi……phJ4qeSJn1rOxgZm9yIHRoZQ==\n
Specifically, a client that wishes to leave an encrypted entry (this means a client
that wants to enter/update an entry to hold encrypted content), has to: 1.
ingest (e.g., from user input) the plaintext message, 2. prepend the CMPUT379
Whiteboard Encrypted v0\n to the plaintext they wish to send, 3. perform
the encryption using the algorithm mentioned next, 4. convert the encrypted
output to Base64 representation, 5. send this Base64 representation in the
update message. Notice that the length being sent (the 128 in the example) is
the length of this Base64 representation which is typically larger than the length
of the original plaintext.
The server, other than remembering the most recent p or c indication for
each entry, treats the contents of the entry in the exact same way. Notably,
the server has no idea about the encryption algorithm and/or the
encryption key used by the clients.
The Encryption Algorithm
Only the client programs implement encryption/decryption. You are going to use
openssl for the cryptographic and Base64 functionalities. This means, typically,
that you will need to link with the crypto library (linker option: -lcrypto).
The encryption algorithm of choice is AES-256-CBC. The openssl library
functions that you will find convenient to use are the EVP group of calls,
3
e.g., EVP_EncryptUpdate after you have initialized EVP_EncryptInit_ex with
EVP_aes_256_cbc() . The way to perform. the encryption and relevant examples
will be presented in the labs. Also, in the labs we will tell you to hardcode an
IV value which is essential to the operation of the encryption algorithm. While
this is not, cryptographically speaking, a good practice, the point of the exercise
is not the production of a cryptographically iron-clad secure application.
You are welcome to use the Base64 transformation library routines of openssl
as well. They belong to the BIO group of calls suitably configured (e.g.,
BIO_new(BIO_f_base64()) ). Again, more examples of their use will be shown in
the labs. Note that the Base64 strings should not be split by newline characters
(option BIO_FLAGS_BASE64_NO_NL).
Client and Server Interface
The client should be callable as the following command:
wbc379 hostname portnumber [keyfile]
here hostname is the Internet name of the host running the server, portnumber is
the server’s port. An optional keyfile provides the key information made available
to the client. The keyfile can contain multiple keys. Each line of the keyfile is
a separate key represented in Base64 format. When encrypting, a client uses
the first key in the file. When attempting to decrypt, the client can go through
each key listed in the file until it successfully decrypts the encrypted message or
until it runs out of keys. Note that it is allowed to receive an encrypted entry
(as a response to the client’s query) for which the client has currently no key to
decrypt it.
It is up to you to provide a minimum human-friendly client user interface allowing
to test the query and update functionality with and without encryption. When
an encrypted message is received for an entry, the client must attempt to decrypt
it and if it fails it should say so. One can add client-user interaction features as
long as the protocol between client and server is not modified. For example, one
can add getting the list of all entries by going through a sequence of individual
query request/responses. The client must also give the user to exit orderly
(e.g., typing an exit command) and to do the same (orderly exit) if it receives
control-C. Upon an error condition, a client must be able to terminate as soon as
possible when it detects the error (this could be an error in the protocol message
it receives), closing the socket of the connection, informing the user about what
happened, and exiting.
The server should be callable as the following command:
wbs379 portnumber {-f statefile | -n entries}
where portnumber identifies the INET-domain port on which the server will be
awaiting connections from the clients. There are two different ways to start the
4
server, and the second argument determines which one is used. The first way is
to provide the statefile which is the name of a file where the server saved the
entries of the whiteboard as they were when it exited at some point in the past.
The contents of this file is identical to what the server would have responded
if it had received a sequence of queries for its entries (in increasing order from
1 to the largest entry in the whiteboard). The second way is for the server to
start “fresh” with entries empty whiteboard entries. Notice that when the server
starts with a statefile it can tell how many entries it has because all of them had
been saved, in sequence, to statefile.
The server, upon starting, turns itself into a daemon process and initiates its
service. It only (orderly) terminates when a SIGTERM message is sent to
it. It is the handling of this SIGTERM that allows the server to dump the
whiteboard contents to a file called whiteboard.all in the directory where it
started its execution. After handling the SIGTERM, the server terminates. This
whiteboard.all follows the format of the statefile. In fact, we should be able
to start a previously terminated execution of the server using as statefile the
whiteboard.all saved by the previous execution of the server.
Notice that several things can be happening in parallel, especially at the server:
new clients can be connecting, while existing ones are disconnecting, queries are
being responded to, updates are being performed, an update and a query to the
same item may be taking place at the same time (or multiple updates at the
same time!) etc. Make sure the information at the server and clients is correct,
complete and consistent. No clients should ever be blocked or delayed because
of the sluggishness of other clients. Likewise, the server should be responsive,
i.e., not defer for later an action that it can perform. immediately.
Deliverables
Since all solutions have to follow the same protocol, you are allowed (and
encouraged) to test your programs by connecting to servers of other groups or
have other group’s client connect to your server. Of course, you are not allowed
to share code.
The language of implementation is C
In the lab machines, always remember to terminate any server dae-
mon processes you have left running before leaving. Generally, ensure
that you have not left any stray processes running on your machine before leaving.
Violations of this rule may be penalized with mark deductions.
Your assignment should be submitted as a single compressed archive file. The
archive should contain all necessary source files as well as a Makefile . Calling
make without any arguments should generate both the client and the server
executables. One item that must accompany your submission is a brief docu-
mentation (can be a single README.txt file) of your client user interface ,
5
allowing the TAs to use your client without guesswork. You are expected to
deliver good quality, efficient, code. That is, the quality of your code will
be marked.
Monday, January 30th, 2017