This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
The analysis and design phase gives a brief view of the protocol implementation of EAP-TLS for authentication and security purposes. The design models includes the sequence diagrams of EAP-TLS that illustrates the conversations between the administrator, client and the server, data flow diagrams and class diagrams.
Figure 4 Admin-client-server models
The above model represents the interaction between the administration, client and the server. The transmission process includes : requesting the certificates for client validation, searching for the files and requesting for server lists and certificates.
The analysis phase includes the following client admin and server interactions:
The administrator must maintain each and every systems status in the form of certificates. These certificates are copied to the other peer too when the conversation becomes successful.
The systems must register to the admin to get the file structure of the server that will be selected from the active list. Thus the peer after getting EAP-TLS success message it will be registered, since before that many conversations will be undergone.
Each and every request accepted by the administrator must be certified containing the necessary information of request ID, file name, session ID, and type of encryption and also the destination information.
The client or the peer asks the administrator for the master session key which can be considered as the private key of the peer and the public key for the server when the data is destined to the peer. So the master session key (MSK) is the main key for the authentication purpose.
The file is encrypted with that MSK and then by the Triple-DES algorithm to complete the double encryption (Hybrid Encryption). So the sharing of the MSK within the systems is most important thing since without that it is completely difficult to achieve the double encryption and data confidentiality and implementation of the Hybrid Cryptography.
Whenever the systems becomes inactive then the administrator drops those IP addresses from the list and just shows the active lists of server IP address. So the administrator will be in continuous checking of the active lists of the devices which helps for the client to know the active lists and select the suitable server for the need.
Whenever the authentication of the peer is cancelled then suitable error messages are displayed in the client for the proper reasons for cancellation so that the system making the request gets to know that the system is down and can't make the request. By the suitable error messages the system can get to know why the system is down and to take the suitable steps to make the authentication success.
The file requested is encrypted twice with the Triple-DES and RSA for double encryption using the concept of hybrid cryptography so that data can't be easily taken in the original format. Thus the intruders can't easily get the key used for encryption and decryption.
4.2 Designing the system
4.2.1 Method Interactions
This phase includes the interactions between the library that consist of different components and the administrator that requests for the information from the library. The transactions included in this phase are transmission of session key, XML sheet for the client, etc ,.
Figure 4.2.1 Administrator interfaces with the library
The above model describes the administration interfacing process with the library.The administrator makes the call to the library for the session key with the help of the following functions:
public void addSessionKeyData (string sKey, string path)
In this method it takes the i/p arguments and generates the session key for the client and adds it in the client XML and stores in the administrator.
public void createClientXML(string filecount, string RID, string filename, string ClientId, string serverId)
In this method a new client XML is created for each and every request and stores in the administrator.
Figure 4.2.2 Client interfaces with the library
The methods included in the above representation are:
public dataset sendServerIP()
This is the request from the client to get the active server IP's of the server's to ask for a file download.
public ArrayList getDirectoriesFiles (string directorypath)
File structures of the selected server is returned and it is displayed in the client to select the server files to download.
public string getSessionKey(string Fcount)
The session key for the particular request id from the client is returned to the client so that he can make the request using that session key i.e. for each and every request a session key is generated.
public string getPublicKey(string RID)
The client asks for the public key of the server to encrypt the certificate of request from the client to the particular server.
Figure 4.2.3 Server interfaces with the library
The server interfaces with the library only during file transfer. The server double encrypts the file and then sends the file to the client through library interface.
4.3 Conversations undergone during authentication
Packet Exchange during authentication
The conversations involved in peers authentication are:
Administrator - Client
Administrator - Server
Server - Client
Administrator - Client Conversation for authentication
Before the client passes a request to the server, registration must be made at the administration which is necessary for validating the certification of the client when request is passed to the server. The entire details of the client will be stored in the certificate which is sent to the server for the client verification.
The administrator broadcasts its IP address to one of its port and waits in another port to receive the reply, thus it waits in the infinite loop for the reply in the receiving port. When the client sends the reply then the administrator get the details of the client, make a certificate of the client and return a copy of the certificate to the client. Thus it saves the state of each and every client and makes a list of the active clients. The client requests for the server list and requests for the file structure of the selected server IP address. The administrator creates a certificate for the client request, creates a request ID and then sends the MSK to the client. When the client gets the MSK then the EAP conversation between the administrator and the client is successful.
Figure 4.3.1 Authentication conversation of client with Administrator
Administrator - Server Conversation for authentication
The server providing the resource first has to register with the administrator for authentication. The server has to give its IP address to the administrator and also the file structure of its to the administrator to create an certificate so that whenever the client selects this IP address and demands for the file structure then the administrator must be able to provide those details to the client. Finally when the EAP success message is returned to the server then the server is authenticated successfully.
Figure 4.3.2 Authentication conversation of server with Administrator
The server also communicates with the administrator in another situation when the client makes a request to the server for the resource. Then the server crosses checks the client IP addresses with the administrator. If the client has been registered with the administrator then the administrator gives the MSK of the client to the server to decrypt the file to get the request from the client. Figure 4.8 shows the conversation held during cross checking of the client with the administrator. Thus between the administrator and server two types of conversation occurs first during server authentication and another one during the client verification.
Figure 4.3.3 Conversation of server with Administrator during cross checking
Thus the server verifies the client with the administrator by sending clients request ID, and clients IP address. If the client is already registered with the administrator then server gets the clients MSK from the administrator and encrypts the files requested using the clients MSK, if not registered then the server sends the error messages to the client and ends the conversation.
Client - Server Conversation for file exchange
The server waits in an infinite loop for the requests from the client in its receiving port. Client selects the suitable file for download from a suitable server and then makes the request with the server and then waits for the request to be fulfilled.
Figure 4.3.4: Server and Client conversation during file exchange
The client selects one of the file from the file structure of the selected server IP address and then it requests the server for its public key to encrypt the request. After obtaining the server public key client encrypts the request certificate using that key and sends it to the server. The server cross checks the client with the administrator and if it is a valid client then it encrypts the data using the clients MSK and Triple-DES and sends it to client. The client decrypts in the reverse fashion and then gets the actual data in a secure fashion.
4.4 Conversation termination scenarios
The conversation termination scenarios include the information about the error messages that appear during termination of conversation. There are many situations where in which the conversation held between the peer and the authenticator becomes failure and terminates. The situations involved are:
1. The administrator authenticates to the client successfully, but the client fails to authenticate to the server.
In this situation the client after requesting the active server's list the client doesn't selects any server or it can't see the required server details so that the administrator sends the EAP-Failure message after the TLS alert message. If the client would have sent the initial handshake message then the authentication process would have been restarted. But the client has sent the EAP response with no data indicating that the client is terminating the connection. The alert message contains the reason for termination it is normally displayed to the other end so that the user can make a log of the error and terminate.
Figure 4.10: Conversation when the client fails to authenticate to the administrator
2. The administrator authentication to the client is unsuccessful.
Here in this situation the client tries to authenticate to the administrator but the administrator fails to authenticate to the client and client sends the alert message and terminates the connection.
Figure 4.11: Conversation when the administrator fails to authenticate
The above discussed conversations are the main thing since the authentication can be cancelled either by the client/server or the administrator. Thus the below mentioned termination types are just the resemblance of the above figures and just a packet may be modified from the shown figures, which packet is going to be changed is explained in the below sections.
3. The client becomes inactive and needs a re-authentication.
In this situation the peer becomes inactive then the administrator will send the TLS alert message indicating the reason for termination. If the client sends the response with the TLS record message containing the handshake message then the re-authentication begins and peer authentication is continued from the first step. Thus when comparing to the above conversation as in figure 4.10 after administrator sending the TLS alert message if it receives the response with the data then re-authentication is continued. Otherwise the administrator sends the EAP-Failure message and ends the conversation with that client.
4. The request comes from the anonymous client.
In this condition the server gets to know about the unregistered peer from the administrator since the administrator maintains the information of each and every peer so that for a request from the server to verify the client, the administrator fails to check the client in its lists and reports the server that it is not yet registered. The server sends the TLS alert message indicating that the client has to be registered with the administrator for making a request and terminates the connection by making sending the EAP-failure message to the client making the request.
4.5 Sequence Diagram
These diagrams are used to model the behavioural aspects of the system.It is a type pf an interaction diagram which shows the interaction between a set of objects, the way they are linked to each other and also the messages, the objects pass among themselves, with respect to time ordering of those messages. The sequence diagram depicts a graph with objects placed along the x-axis and message passing along the y-axis. The y-axis proceeds downwards with respect to increase in time. Beneath each object, its lifeline (dashed line) is drawn along the y-axis, which indicates the existance of the particular object for a particular time period. Objects can also be created or destroyed in the middle of the sequence diagram, as soon as a message sterotype"create" or "destroy" is received.
The time duration during which a particular object is active is indicated by a vertical rectangular box called as "Focus of Control".
Figure 4.5.1 Sequence diagram between client and admin
Figure 4.5.2: sequence diagram between client and server
The sequence diagram of the client and the server represents the methods used to perform the action between the client and the server and also about the function operation.
Figure 4.5.3: Sequence diagram for the interaction between admin and client
This sequence diagram represents the admin and server interactions and what all the methods used and also about the way of communication.
These are the sequence diagrams of the interaction between administrator, client and the server in the present project. The interaction is shown by the help of methods communicating with the other.
4.6 Data Flow Diagram
A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFD's can also be used for the visualization of data processing (structured design).On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process. A DFD provides no information about the timing of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored.
Administrator working can be shown in the data flow diagram as shown below in figure 4.6.1
Figure 4.6.1: Data flow diagram of the administrator
As shown in the above Figure the administrator does the following things
First the administrator broadcasts its IP address to all of the clients and server connected to the administrator through the receiving port.
The IP address is received by the clients and the active clients and the server are listed in the XML sheet.
2. Server functionality
The following Figure shows the server flow diagram.
Figure 4.6.2: Data flow diagram of the server
As shown in the above flow diagram of the server, the following steps take place.
First the broadcasts message of administrator's IP address is collected from the server and it saves the administrator's IP address.
Then a particular client may send the request for the files in the file systems of the server.
The client data flow diagram is as shown below.
Figure 4.17: Data flow diagram of the client