Back to the Table of contents

Part 3: File synchronizer security

1. Security problems in the original version:

1. Anybody who knows the machine where the server is running, the port number, and the interface that it uses, can connect to the server, get the  FileSystem,  and hence gain the access to the files;
2. Somebody who knows that I'm about to run the synchronizer, can start a fake server, which would give my synchronizer a fake  FileSystem  object, and cause the program to synchronize my files with that file system, which can result in destruction of my files, and/or their disclosure.

2. A more secure design:

• Assumptions:
  • secure socket connections; otherwise all the information that is being sent must be encrypted, and the synchronization would be too slow;
  • secure file systems; otherwise making the synchronize more secure doesn't make sense;
  • a trusted system administrator;
• Policies and general ideas:
  • we only need to worry how to get the network reference to the remote  FileSystem  object; after that all calls to its methods should be secure since we assume secure sockets;
  • the server has two keys: server key and client key; these keys are unique for each "incarnation" of the server (i.e. if the server has to be restarted a new set of keys must be generated);
  • each client that wants to use the server must present it the client key in each call to the server's methods; each client that wants to verify the authenticity of the server must know the server key;
  • to make sure that the server is not an imposter, the client can request the server key from the server, and compare it with the one that it has.

3. Implementation (and possible variations):

• the client generates, or takes as line arguments, the server key and the client key. The server is started with these keys as line arguments (for additional security the keys can be put into a file and the server is given the file's name as the argument; this is not implemented, but can be easily done).
• when the client asks the server for a  FileSystem  object, it passes the client key as an additional argument; if the server wasn't started by this client, the client must know the keys that the server was started with;
• after receiving the  FileSystem  object, the client verifies the authenticity of the server by calling the  ServerImpl.getSkey()  method (which takes the client's client key as the argument); if the check key received from the server doesn't match the client's server key, an exception is raised;
• the server returns a  FileSystem  object or the server key only to a client that gave the correct client key as an argument in the request; otherwise an exception is raised;
• a more secure variation can easily be implemented here: the server key and the client key are used by the server to generate a file name; the server reads the file and returns the contents to the client in response to the  ServerImpl.getSkey()  call; obviously, the client must know what is the contents of the file, the best for the client is to put something into this file right before the server verification; this is not implemented, and for the purposes of the exercise seems like an overkill.
• it is important that the client verifies the authenticity of the server after getting the  FileSystem  object, otherwise a fake server could be installed during the gap between the verification and getting the file system (it is not very realistic, but theoretically possible);
• it might seem dangerous to pass and return the server key and the client key; but since the keys are unique for each server, the following type of attack wouldn't work:
  1. detect a running real server; crash the machine; install a fake server;
  2. get the client key from a real client that is trying to use the server;
  3. quit the fake server and wait for a new real server to start;
  4. use the client key obtained in step 2 to get a  FileSystem  object and the server key;
  5. use the  FileSystem  object to read/write/delete files;
  6. crash the real server again and use the server key from step 4 to fool clients.
  The problem with this type of attack is that the client key from step 2 is not valid for a new real server and can not be used in step 4.
• The timing results presented above were taken with the security features implemented, but I don't think there was a loss of performance.