SDFS Report / System Documentation
Jonathan Kron and Renelle Francis
Implementation Details
Architecture
The entire system is broken up into four directories: Client, Server, Certificate Authority,
and Common. The Common directory contains shared libraries that are used by all three
components. These include the packet creation, parsing and information methods, SSL
connection and listener classes, an error class and the certificate authority client classes.
The Server directory contains the server and filesystem, the Client contains the client
code, and the CertificateAuthority directory contains the certificate authority. Each
component has a MyCerts directory, which contains the component’s own certificate,
public and private key, and a TrustedCerts directory, which contains the certificates and
public keys of trusted machines.
The system works as follows: The client can perform PUT, GET, DEL and WAIT
commands. For each of these commands, the server and certificate authority must be
active. The PUT command will place a file in the server’s filesystem, the GET command
will get a file, and automatically send a token if necessary, the DEL command will send a
delegate to another client, and WAIT will put the client in receive mode, waiting for a
delegate.
On a connection from the client, the SSLconnect code will automatically query the CA
for the certificate, which, if it exists, will be downloaded to the client’s TrustedCerts
directory. The filesystem will do the same thing for public keys when it needs to check
the validity of a token.
The individual details for each component are listed below, and the protocols are detailed
farther down in this document.
Server
The server uses the SSL and BIO libraries of OpenSSL to create a listener that will block
until a connection comes in. On a successful connection, the server will then block on a
wait for message. When a message is received, it is queried for its message type, which
gives information as to its purpose. The types of messages the server can receive are as
follows: PUT, GET, TIME, CLOSE. The PUT command will be sent to the filesystem
with the hostname, filename and filebuffer and the GET command command will also be
sent to the filesystem with the hostname, requested filename, and optionally, a token.
The TIME command will return the server’s UNIX time, used for creating delegates that
have accurate expiration times, and the CLOSE command which puts the server back into
wait for connection mode. Each of these commands will respond back with a message,
either containing a file, a time, or an error or success message.
The filesystem uses the OpenSSL encryption libraries to encrypt files according to the
project specification. On a PUT, a SHA1 is performed on the file buffer. The file buffer
is the encrypted using the SSL Blowfilsh encryption algorithm, with the SHA1 key as in
the input to the key function. Then, this key is encrypted with the server’s RSA public
key. The filename, owner, key and encrypted file buffer are then stored in the servers’s
FS directory. A success or failure message is sent back to the client. On a GET, the
filesystem compares the hostname requesting the file to the owner of the file. If they
match, the key is decrypted from the file metadata using the server’s private key, and the
Blowfish decrypt function decrypts the file, which is then sent back to the client. If the
hostname doesn’t match the owner, and a token has not been provided, the server sents
back a request for a token. Then, the client will send a token. The token contains the
owner hostname, the requestor hostname, the expiration time, and a value which is the
signed value of the information in the token. This information is signed by the private
key of the owner client. The filesystem will then request the public key from the CA,
check the signature, and either accept or reject the token based on the results of the
signature, and the value of the expiration time. An appropriate message is then sent back
to the client.
Client
The client uses the SSL connect code to connect to the server. The SSL connect code
will download from the CA the appropriate certificate based on the hostname that it is
trying to connect. Then, the connection will succeed if the certificate is correct. The
client works by passing in command line arguments depending on what the user wants to
do. The arguments are detailed in the readme, but the basic commands are PUT, GET,
WAIT and DEL. The PUT and GET commands will form a packet and send it to the
server. The DEL command will ask the server for its time, create a token that is signed
with its private key, and will then transfer it to a waiting client. The WAIT command
will put the client into a WAIT mode, where it will await a DEL message from another
client.
Certificate Authority
The certificate authority will wait for a connection. Then, on a successful connection, it
will await a message requesting a public key or a certificate, based on a hostname. It will
read the raw file into a buffer, send it back to the CA client code, which will write the
certificate or public key into the TrustedCerts directory of the client or server.
Protocol details
PUT:
The client creates a PUT message containing a PUT enum, the hostname length and
hostname, the filename length and the filename, the file size and the file buffer.
The server receives this message, parses all of the fields, creates a file in the filesystem
which stores the encrypted SHA1 key, owner, filename and file size as well as the
encrypted file. The server sends back a RESPOND message, which contains the
hostname, a SUCCESS or FAIL sentinel, and, in the case of a fail, a message length and
message. The client will display the status to the user.
GET:
The client creates a GET message contained the GET enum, its hostname length and
hostname, the filename length and the filename. The server then parses this message and
responds back with either a GET_RESPOND success message (which contains a buffer
containing the filename, filelength and file, a RESPOND fail message, or a
REQUEST_FOR_TOKEN message. If the REQUEST_FOR_TOKEN message is
received by the client, the client looks in it’s Tokens directory, looks for a token named
FILENAME.tok, then sends back a GET_WITH_TOKEN message to the sever. This
message contains the same information as the GET message, but with a token length and
token. The token contains the filename, owner, hostname of requestor and expiration
time as well as a signature of this data. The server receives this message, parses the
token, checks to signature, expiration data and validity of the data, and responds with
either a GET_RESPOND, or a RESPOND message with the cause of failure. The client
receives this message, and if successful, writes the file buffer into the Downloads
directory.
Delegation:
The server and CA must be started. The receiving client should be put into WAIT mode.
The token creating client sends a TIME message to the server, asking for the UNIX time
of the server. The client then receives a TIME_RESPONSE, or a RESPOND with a fail
message. The TIME_RESPONSE will contain struct timeval with the UNIX time. The
client will then generate a token buffer containing its name, the requestors name, the
filename and filesize, and the expiration time which is calculated based on the server’s
UNIX time. This token is then sent to the waiting client using a DEL message. The
client receives the message, writes the buffer into the Tokens directory, and responds
with a RESPOND success or failure message.
Certificate Authority
The client or server sends either a CACERT or a CAPUBKEY message containing the
hostname and hostname length of the requested certificate or public key. The CA then
responds back with either a buffer containing this data, or a RESPOND failure message
indicating a failure.