Security

Access control

R. Absil P. Hauweele

Academic year 2021 – 2022

This document quickly reviews a few access control techniques and principles to implement
on a basic client / server application, in Java.

Introduction

Access control is a core concept in sensitive computer systems. In general, a secure system must
at least implement the following features:

• confidentiality: sensitive data can only be accessed/read/interpreted by actors who have

the right to do so;

• non repudiation: when a transaction t is performed between actors x and y, making sure
that x and y are who they claim to be, and that none of them can deny taking part in t;

• integrity: alteration of data/commands transmitted between two actors can be easily

detected.

For the purpose of this lab, we will use a minimal1 client/server application implemented in
Java. The main components of this application are:

• BasicMessage.java and MsgTypes.java: classes modeling simple messages, used by both

the client and the server;

• BasicServer.java: classes modeling the server’s side of the application, namely, a simple
class for the server, a utility class (BasicServerThread) to model a session, and the
interface BasicMessageHandler as the handler for messages of specific types (this interface
will have to be implemented for each message recognisable by the server);

• UserDB: a simple interface to store (resp. retrieve) users into (resp. from) a file;
1
For the sake of simplicity, and to solely focus on security, we will shamelessly and with impunity violate nearly
every single software engineering principle regarding the design of client/server applications.
 Access control 2021 – 2022

• BasicTextClient.java: a simple class to model a client able to send text messages to a

server;
• ClientMain.java and ServerMain.java: the two main files allowing to launch the client
and the server, respectively.

Note that the files ClientMain.java and ServerMain.java can be used as tutorials showing
how to use this small framework.

There are only three predefined commands in this application:

• telling "You killed my father" to the server, that answers "No, I am your father";
• telling "Hello there" to the server, that answers "General Kenobi!";
• closing the session.

Note that, concretely, these commands are handled a bit differently.2

In the next section, the objective will be to implement several security principles. More
precisely, we will take the following steps:

1. implement a basic password-based authentication;

2. making sure that non-authenticated users cannot use restricted commands;
3. making sure that transactions cannot be replayed.

Note that while this lab provides exercices to illustrate these concepts and implement security
features, they do not concretely detail how to implement them. It is a soft skill you are expected
to develop. You are encouraged to think outside the box.

For the sake of simplicity, we will consider that:

• the server has a pre-generated RSA key pair;

• every client has, at any time, a copy of the public key of the server, and the ownership of
this key can be trusted.

Clients will generate their own pair of keys when needed, and these keys will also be trusted by
the server. For that purpose, the classes MessageDigest, Cipher, KeyPair, KeyGenerator and
SealedObject from the Java standard will most likely be useful.

This scheme is clearly flawed, mainly in terms of certification and associated security features.
For that reason, it is possible that some of the exercices that are given are artificial. These
problems will be addressed in the next lab, as this one focuses on access control and protection
against replay attacks.
2
For modularity, it is considered that the client accepts commands, made out of an initial string followed by
potential data. There are three predefined commands: HELLO, FATHER and EXIT. It is then expected that FATHER is
followed by You killed my father and HELLO by Hello there. Depending on the type of command, the client
then builds up a particular message type, later written down to the stream linking the client to the server.

2
 Access control 2021 – 2022

Submission

Projects can be implemented in pairs (groups of 2 students), and must be submitted with the
help of a git repository3 . For that purpose, send an email to your teacher on 10 April at 23h59 at
the latest with the URL to your repository, and the name and matricule of your group members.

You have to submit your work on 24 April at 23h59 at the latest. The minimal requirements
for submitted projects are as follows:

• projects have to be submitted on time,

• projects have to provide a readme file

– mentioning the name and matricule of your group members,

– explaining how to build your project4 (we recommend here to either provide a makefile,
or a shell script to install missing dependencies, compile the project and run relevant
scripts),
– explaining how to initialise and/or launch the server and the client.

Projects failing to meet these requirements will not be graded (that is, they will get 0/20).
Furthermore, note that we shall in no way build or run your projects in an IDE.

Exercises

For the following exercices, we will ask that you add several features associated with security in
the basic client/server framework that we provided. For that purpose, we advise that you create
new message types, message handlers, etc. While you are free to modify the code we provided in
any way you want, it should be enough to add enumerators in the MsgType enumeration, and
then only work from within the ClientMain and ServerMain classes.

Exercice 1. Implement a basic password-based user registration scheme, that is, create a message
type allowing non authenticated users to ask for the creation of their user account.

When a user asks for an account to be created, he provides a login and a password matching
the policy5 . The login has to be unique.

Note that it is expected here that users’ passwords are transmitted and stored securely, that
is

• passwords are ciphered with RSA (2048 bits) when transmitted from the client to the
server,
3
Create the repository yourself, add your teacher as maintainer.
4
Projects that do not compile will not be graded.
5
Passwords are assumed to be between 6 and 8 alphanumeric ASCII characters.

3
 Access control 2021 – 2022

• passwords are salted and stored hashed using 100 passes through the PBKDF2 hash
function6 .

In order to persistently store users, we demand that you use the UserDB class. This class is
able to associate any login to an arbitrary amount of data, with the help of the parameter
byte[]... fields. This information is transparently (un)serialised for you, so no modification
of this class should be required.

Exercice 2. Implement a simple authentication scheme so that registered users can authenticate
providing their login and password.

Exercice 3. Make sure that messages of type FATHER are only processed for authenticated users.

Exercice 4. Implement the following challenge-answer scheme so that no message can be replayed

1. when actor x sends a message to actor y, he includes an encrypted random integer n1 ;

2. when actor y answers, he provides n1 ` 1 (to be checked by x), and includes an encrypted
random integer n2 ;

3. When actor x answers, he provides n2 ` 1 (to be checked by y), and includes an encrypted
random integer n3 , etc.

For the purpose of this exercice, it is probably useful to create a class NonReplayableMessage
packing up an integer (to be checked according to the above scheme) along with a BasicMessage.

6
It’s probably useful to have a look at the Java classes javax.crypto.spec.PBEKeySpec and
javax.crypto.SecretKeyFactory