grapedraughtSoftware and s/w Development

Dec 2, 2013 (4 years and 7 months ago)


Final Report

SID 199922820

Simon C Milson






Final Report

Submitted for the

BSc Honours in Software Engineering

Simon C. Milson

SID 199922820


Final Report

SID 199922820

Simon C Milson







Initial Brief


Analysis of the scope of the ini
tial brief


Project time concepts


Extended analysis of brief


Project Structuring


Time management strategies


Timescale chart (see appendix 8.0)


Project Portfolio


Code Journal


Component breakdown


Object classes


Encryption and Key management


The client GUI


Online Interface


Data Manipulation and storage






Key Encryption


Encryption algorithms


Java Techniques


Java resources employed





Java Streams


Java Key Management


Key Installation


Java File Distribution


Java Database Access




Code Journal

Final Report

SID 199922820

Simon C Milson






Testing Journal


Exception handling


Testing Java keytool


Server Testing Applet


FirstSQL Database usage


Java Policy

Files (Intelect Server v1.3)



Project Summary








Current state of project


Goals still to be achieved




Research techniques


Referencing techniques used within this project




Web sources


Other Resources



Code Library


Application Semantics


Glossary of terms within the context of this document


Time management printouts

Code printouts

(Separately indexed)

Final Report

SID 199922820

Simon C Milson





Title: BlackBook address book

1 Initial Brief

The idea for this project has

come around due to a practical problem I was
having on my home system.

As a reasonably heavy Internet user over the last few years, I have developed
a large volume of logins, passwords, email addresses and URLs.

This is due partly to the fact that bes
ides having a site URL to remember,
many sites also have different methods of registering new users. Often a
unique user name is requested; sometimes an email address is used and
occasionally a random name is generated. There are also sites that require
assword retrieval questions” generally regarding parents or fluffy animals!

Currently all of this often
sensitive information is stored in a simple, un
txt file. This file has become a general catchall for all sorts of other
miscellaneous items in
cluding a backup of my mobile phone address book, a
list of emails, my ftp’s and passwords and my email servers and logins.

A second problem that I have found recently was during travel away from my
computer. Whenever I required access to the Internet it
was only possible to
access the sites whose details I had committed to memory. The only other
way would to have taken a printout of the list of details with me wherever I go
which would not be acceptable in case of loss.

The answer to both these problems
would be to design an address book that
could store all of this information in an encrypted form both on the users hard
disk for use when they online at home and uploaded to a secure server online
for access when away from home.

Access to the address book

would be provided through a user login screen.
New users to the address book can only be added through an administrators

The data stored by the address book would need to be stored in an encrypted
form on the hard disk, this is especially import
ant in the case of passwords.
Online access to the book must be allowed only through secure servers to
minimise the effect of security issues commonly found on the Internet.

Passwords stored for the sites will be viewed on the screen either in an
ed form or in a standard form. This can be set on creation of the new
record and can be changed, possibly only through an administrators account.

The address book will store all of the usual information about contacts, more
than one address can be added
representing work, home, second home
addresses. The same with phone numbers to include mobile numbers, fax
Final Report

SID 199922820

Simon C Milson





numbers, home numbers etc. Email addresses and online handles eg. For
ICQ and MSN Messenger. At this point those are just the basic details that
be added. The design phase will develop this to include other required

One of the most important features of the address book is to store information
regarding websites. A profile of the site can be entered for reference and
multiple URL’s c
an be stored along with login information. Multiple logins can
be added for sites where more than one account is used.

As mentioned the address book will include storage of FTP site details both
for web space the user owns and for logging onto other com
mercial FTP sites.
The user can also add details for their Internet dialup’s

such as dialup
number, login name, ftp details etc.

The initial design work due to the large scope of the project will be done using
UML within the Together J environment. T
ogether J allows a project to be
developed through from the initial basic concepts gradually extending the
ideas using different methods such as class diagrams. This allows the
individual classes to be shown including the properties and operations within
he classes. It also enables indications to be shown of the relationships
between classes.

Alongside this some of the GUI design will be undertaken using Borland
JBuilder. This will allow quick, easy visualisation of how the widgets see
glossary will fit
together and interact when the user runs the address book.

I believe that this project offers sufficient scope to fill the role as a final year
project. The address book design can be continually evolved to include
information about the contacts that woul
d not have necessarily been included
from the initial point of design. The different types of information that are being
stored such as FTP sites, Websites etc can be extended to include other
items of importance.


2 Analysis of the scope of

the initial brief

The overall scope of the project can be defined as the design, construction,
testing and implementation of all of the required components. Essentially this
requires the complete development and deployment of a secure, quality,

application with appropriate supporting documentation.

This project brief should enable coverage of many of the aspects and
techniques associated with Software Engineering. It is also expected that a
wide variety of new programming techniques will be en
countered and
employed along the life cycle. The theme of the project is geared towards
introducing aspects of Java programming that are of interest to the
programmer. Another justification of the chosen idea pertains to the possible
Final Report

SID 199922820

Simon C Milson





career choices of the
programmer. When making use of the Internet, security,
encryption, client/server application and database access all become
important features to consider. Any type of knowledge gained within these
fields will be invaluable when considering job application
s requiring Java
background in them.

2.1 Project time concepts

This basically equates to the processes undertaken by all commercial
software houses through the evolution of their own software products. For the
more extensive software developments, proje
ct teams are created with team
leaders assigned. Team leaders are required to coordinate every aspect of
the development process and provide a central figure in each team for
individual members to liaise with and report to with issues and queries. For

occasions they may offer no actual technical input regarding the
development of the project, rather they act as an overseer ensuring all areas
of their component development runs smoothly.

Professionals in the required areas of programming are usually i
house. It is
however possible that project contracts be acquired requiring a specific
knowledge base not currently employed by the company. In such
circumstances there are two usual courses of action:

The first is to enhance the project teams lacking in

certain areas with free
lance software engineers on short
term contracts. They are assigned to work
in unison with the rest of the team, either for the duration of the project or until
their input to the design of the project is no longer needed.

The sec
ond is to sub
contract certain portions of the design to an external
software house. Upon acceptance of the contract, the chosen software house
undertakes the responsibilities entailed with the completion of that sub

Which method is employed inva
riably depends on the circumstances
surrounding each individual project but the fact that these methods can be
made use of greatly enhances not only the quantity of contracts that can be
attempted but the range and diverseness.

Successful structuring of
both resources and time is critical in providing
reliable software within specified deadlines. Experience is invaluable in these
areas when deciding the workloads and time slots allocated to each specific
component of the project
cycle. Any significan
t misjudgements on a
certain aspect may not only hinder the progress of other teams work, but the
progression of the finished application itself.

While a large complement of skilled employees and resources allows the
allocation of the increased workloads
over a range of departments, it does
present the obvious problems related with distributed code development.
Individual teams may have little knowledge of other teams involvement in the
project. Administrative issues in terms of project management must be
addressed along with ensuring consistency in programming styles, internal
Final Report

SID 199922820

Simon C Milson





code portability and code encapsulation. Most importantly morale level is
directly linked with productivity, and within larger organisations of people
fluctuations may have considera
ble impact

When this is contrasted with the freelance individual programmer (i.e. working
solo without company), the reverse pros and cons are applicable. An
individual designing an application will have a complete overall view of how all
aspects of the
project should be designed, deployed and integrate with the
other aspects of the project. The involvement at all stages of design greatly
improves the ease of debugging

especially when bring separate portions of
code or components of the application toge

Again there are obvious drawbacks to the solo programming. One of the main
issues comes with size and diversity of the workload that can be attempted.
An individual will never be able to accomplish the same quantity of results
within the same timesc
ales as large teams of programmers.

Another negative implication of individual programming is that the knowledge
base relied on for design extends only to the knowledge of that single
programmer. Successful coding also requires the correct application of

knowledge. Although many resources are available to search for methods and
answers to problems, such practices must be allowed for when estimating
timescales. Subject areas that are completely new will require extensive
research in order to ensure re
levant knowledge is in place before coding

Detailed research coupled with immediate implementation of the ideas
suggested by that research does present one long
term benefit. In many
cases the methodology employed is committed to memory for fu
ture use.

When appraising contracts in both circumstances, the amount of research
necessary must be taken into account with regards time constraints.
Alongside this the degree of relevance of the research must be evaluated with
regards relevance to the c
urrent chosen market
place areas, or markets
trends. I.e. if any projects in the future are likely to make use of these new
techniques as well.

By nature of the Software Engineering Degree, this project takes form as the
latter. Time constraints are gover
ned by the overall project deadline, which is
specified as being one day before the end of the Christmas
Easter lecture

A large degree of this project will entail in
depth research into many areas of
Java programming that have not been touched be
fore. Java Cryptography
and Java Networking contain extensive packages that provide valuable
foundation tools for creating secure usable network connections worldwide.

While the foundations of communication over the Internet can be complex, the
Java API
provides abstract and complete implementations to provide much of
this functionality in a more simplistic manner but still allow extensibility. This is
not to say that these classes can be applied ad
hoc. The Java API only
Final Report

SID 199922820

Simon C Milson





supplies the relevant methods to
be made use of. Successful utilisation of
these still requires instantiation and initialisation to occur in the correct
manner. Instantiation will require the correct parameters to be passed; often
these parameters will be of an unknown type.

Research pe
riods usually ensue the occurrence of these unknown
parameters. Such periods may be short or may occur over a longer term
should more classes need developing and extended research needed. This
volatile nature creates difficulties when attempting to assign
time slots and
meet inter
project deadlines.

A tangent may introduce a new concept essential to the project (that could be
defined as a sub
) that had not been required at earlier
stages. Extensive research and class development may b
e necessary to
create the required instances of variables to be passed through thus
continuing the flow of the body of the project.

More often than not these factors can be dealt with efficiently when extended
resources are available as in larger compan
ies. However they may have
serious time implications should an individual programmer have to undergo
periods of unplanned research.

2.2 Extended analysis of brief

Initial drafting of the project component breakdown required broad research
into the techni
ques necessary to complete all components of the project life
cycle. Java security covers a vast area that will almost definitely require
development for many aspects of the project.

The use of encryption is of paramount importance when dealing with secur
transmission over un
secured networks such as the Internet. Encryption can
be applied both to the actual data and to the connection itself. Transmitted
data blocks contain commands to invoke methods within the client/server
applications and access the da
structure stored there. Client access can be
from a client local to the user or from the web
applet client.

A sound foundation in Java programming has been attained in the first two
years of study, which will allow structured competent use of the stan
dard java
programming/object oriented features. However knowledge on all areas
mentioned in the above paragraph will be limited at best due to their more
specific nature.

Extensive time periods will be necessary especially in initial stages but the
need w
ill certainly arise to deviate along new avenues.

When taking all of these mentioned variables into account, it can be seen that
it is impossible to judge to any degree of accuracy the time needed for each
new aspect of the project. This project aims fir
stly to embrace techniques
used in the competent design of software, and also to research and develop
as many new techniques relevant to the creation of the application within the
time constraints allowed.

Final Report

SID 199922820

Simon C Milson





3 Project Structuring

3.1 Time management strat

A secondary issue that will come into play is the coursework and reading time
required by the other modules being read this year. Certain deadlines will
require more time to be allowed at certain dates for coursework completion
and less for project
work. This will have to be addressed when setting critical
design points in the project and assessing work
levels needed regarding
coursework deadlines coinciding with project deadlines.

There is a two
week exam period allocated in the final weeks of seme
ster one
and 4
week in semester two. Time will need to be allowed for revision in the
preceding weeks and the final preparation in these exam weeks. It is
expected that very little project work will be attempted, certainly in the exam
period and the projec
t will need to be left in a suitable state so it can be left
and returned to during the holiday period.

As the project progresses it is likely that there will always be work of some
kind going on in the background. This is more likely during coding stage
s, for
example when an idea on how to go about something or fix something may
occur and four hours of coding ensues.


Timescale chart
(see appendix 8.0)

The timescale chart is only a first attempt to break the project down into
manageable chunks and le
ave some indication as to where t2he cycle will be
at a given point. Obviously this is only an initial framework and is liable to
change at any time. The final few weeks of each semester, especially
semester 2 may change somewhat depending on exam workload
s and
coursework deadlines. It doesn’t give specific tasks to be achieved only an
indication to at what area I should be working on or around each week. A
more detailed analysis will be performed for entry into the initial report.

Report work and testing
are ongoing processes within the project life cycle.
There is no specific time set aside other than the periods designated in
second phase of development.


The appendix contains three versions of the timescale; the initial handed in
version, a v
ersion revised over Christmas period and a final version revised
around the end of the report hand in time. Each indicates how the time was
spent throughout the project life cycle but can only be taken as approximate at

3.3 Project Portfolio

The Pro
ject Portfolio is loosely defined as all material used in the analysis,
design and implementation of the project components. All of the items
associated with the project come under this umbrella but the portfolio does not
exist as a physical entity.

Final Report

SID 199922820

Simon C Milson






files associated with the project including but not limited to:


written Java code files, pre


compiled Java files that can be interpreted;


application parameter file;


java Jar file, this can be either si
gned or unsigned;


java keystore files;


generic keystore files;


certificate files;


signed certificate request file;


webpages used to host the associated applets;


certificate stored in alternat
ive format;


batch files used to simplify execution;


summary files used to keep records for each version;


java policy file defining applet permissions;


project report files;

Continued project research has also created a

large list of web resources,
mostly in the form of html links that can be found in the bibliography with
some pdf. Format files.

Various external products may play a part in the design. These products will
either be of a freeware nature or will be used u
nder provision of the licence of
that project. Some products may be used under a testing situation only
however this will be the case for the whole project as it will not be for
commercial release.

The Report forms a major part of the portfolio and serve
s as a central
collection point for all ideas regarding the project. It also contains many other
documented items including the Code and Testing Journals and various
stages of analysis of the research done.

The project Portfolio contains research into encryption techniques. This will
probably begin with discussion on proposed methods to be employed along
with background research.

Working example classes need to be drafted to give an ind
ication on how the
methods will work. These drafts will be evolved including implementing the
relevant relationships into the working classes to be provided for the
encryption component of the project.

This research material will be discussed in the Fina
l Project Report, but the
bulk of it will likely be summarised and only referenced depending on project
word limit constraints.

3.4 Code Journal

Initial attempts will be made to keep a running code journal detailing all
incidents where alterations are mad
e to a portion of code. Obviously during
heavy coding sessions specific referencing of every minor detail may not be
Final Report

SID 199922820

Simon C Milson





necessary and a brief overview and key point analysis would be more

This will also serve as a point where reference to when
bugs occur in the
early stages of coding however as testing becomes more extensive a bug
journal will more than likely be kept to keep a record of all fixes to pending
and completed.

The journal will provide a detailed analysis of the coding process an i
how the coding progressed within the timescale and constraints. Hopefully it
will also offer some form of reasoning for any areas or components that may
stray from their time constraints and ultimately give a good representation of
the life cycle o
f the coding detailing at what point the project was at in coding
terms any given time.


4 Component breakdown

Currently the project can be split up in programming terms into a number of
generalised components:

The object classes;

The clien

the front
end version of the project;

The online interface;

Encryption and key management;

Data manipulation and storage;


Determining the complexity of each of these stages early on in the Project Life
Cycle will aide the development of a

realistic timescale for each development
section. The boundaries will need to be flexible to allow for unforeseen
circumstances that may increase or decrease the time required on certain
areas. Determining reliance’s is also an important aspect for consid
Some components may require others to have been developed (although
maybe not to the final stages) before they can be completed or even

Obviously there will be quite a large degree of blending between the sections
and it is at these t
imes the timescale needs to be flexible to allow the different
areas to be developed in parallel and pulled together when it is necessary.
This is represented in the timescale (see appendix 8.0)

with the double entries
in description. On some occasions mor
e emphasis will be placed on one area,
as more work is needed there and vice versa.

4.1 Object classes

The object classes describe the objects that the program uses to store data in
a retrievable manner. The way some of the persistent objects beh
ave will
Final Report

SID 199922820

Simon C Milson





have a strong influence on the functional aspects of the GUI and to a certain
degree the aesthetics.

Where necessary the objects will incorporate recognised methods for
retaining integrity to maintain a valid state. Java incorporates methods f
catching and vetoing alterations to bean data and gives us a way to create
contained data objects that cannot be placed in an invalid state.

Objects allow a degree of extendibility to be built into the program. Each
object is self
contained and e
ncapsulates an idea such as a person, a car, an
ftp, a keypair instance, a cipher instance. Correctly structuring a program to
allow for the use of these will enable extensions in the form of new types of
data to be added with only a few adjustments to the

code to read them and to
the GUI to display them.

When coupled with object relational databases, java objects provide a
powerful tool. An object type can be created containing all of the related
information. Instances of this object can then be created,
manipulated and
then stored in a field in the database as if it were a standard type such as a
string or integer.

4.2 Encryption and Key management

A large portion of the project is to be devoted to the encryption component of
the project. As this field
is completely new to me it will require a high
proportion of the initial project time to be assigned to research into how data
encryption techniques are employed within the industry.

This preliminary research will need to be both generalised (throughout
field) to give a good, broad understanding of the overall picture and
specialised. The specialisation will be aimed towards the implementation of
secure data storage and transfer within the java development environment
that is to be used for the implem
entation of this project.

As the research becomes more specific, sufficient knowledge should be
achieved to begin to piece together subclasses to provide implementations
relevant to this project. These should demonstrate how secure encryption can
be empl
oyed, both to data as it is stored and to a connection for secure
transmission of the data to a client machine.

Online communication is in general maintained using keys and keystores with
various techniques available using combinations and extensions of
both of

Once this stage is achieved, the techniques can be applied to the classes
required for encryption within the project.

4.3 The client GUI

The way in which we wish the user to interact with the program will likely have
implications regardi
ng some of the fundamental decisions when it comes to

Final Report

SID 199922820

Simon C Milson





The graphical user interface will be the front end of the completed product that
is visible to the user and although would appear to have plenty of time slots
allocated to it should certainly
not be neglected in any way in the early stages.
The layout, feel and implementation type of the GUI will have dependencies
on the makeup and storage methods of the data it is to display.

It is likely that design work on the GUI will start in the early s
tages of the
Project Life Cycle. Having a visual representation of what the final project will
shape towards will have benefits when it comes to understanding what the
program must be capable of doing and as such what the code must be
capable of doing.

There is a high probability that graphical design issues may need to be
resolved early as they directly affect the way in which the GUI will b

In the first instance, the concern doesn’t particularly lie in the aesthetic
properties the GUI i.e. Thought should be paid to how the widgets will be
manipulated by the methods within the data manipulation component. How
the data is trans
ferred from the encryption to the screen will also have to be

The type of widget we use may depend on the GUI design tools or java
implementation utilised. Changing between the standard ‘java.util.awt’ and the
‘javax.swing.*’ package may limi
t or enlarge the amount of control or features
defined for that widget. This may in turn help or hinder the way in which code
has to be written. The sooner a degree of choice finalisation can be reached
before proper coding begins, the greater time will be

available for making sure
the other components interact correctly when merged together towards the
end of the timescale.

4.4 Online Interface

This component will be evolved in line with the second phase of the
encryption component as its progression is r
elated to successful
developments involving secure data transfer. The interface will involve a
version of the desktop GUI, possibly a simplified version that can be accessed
from a remote server.

Currently the plan is to start with the low
level connectio
n classes using basic
url’s over a urlConnection to get data over the connection. The progression
into using socket connections will begin to allow the development of methods
to allow streams to be associated with these connections and ultimately wrap
encryption streams around this for the secure transfer across the

The server at the other end must have the required java applet installed to
recognise the incoming requests, connect with the users computer and verify
the authenticity of the
connection. Once this is achieved a secure connection
can be established ready for data transfer.

Final Report

SID 199922820

Simon C Milson





The online module itself must be capable of receiving data through this
connection and updating the databases currently held securely on the server.

It wil
l of course also provide the online interface for the user when travelling,
to access the database securely through any system used around the world.


During the course of research and development, the structure of the model
defining the online m
odule has been changed somewhat. It became apparent
that an optimal setup involved the use of a client/server class pair to setup the
encrypted connection.

The purpose of the server is purely to send and receive data Secondary
classes would handle the ac
cess from the server to the database. These sql
interface classes will also need to handle requests from the graphical online
interface to serve the users online actions/queries.

Incoming data requests are passed to a parsing class, designed to extract t
command information and the data blocks to be operated on (if any). The
class will also act as a protocol handler to decode the command components
to determine the action to be taken.

This information can then be passed the appropriate interface class
, which will
in turn perform the executions associated with that command. A return value
may be involved for example query answers in the form of a byte[] , or an
update success result in the form of a boolean.

If a return value to the client is required
, the value must be passed to an
intermediate encoder class before it is returned to the server. The function of
this class is to prepare a statement in the correct syntax for the protocol in
operation between the client and server. Once this is complete a

generic send
data method is called within the server with the statement passed as an

Both of the parser/protocol handler and the encoder classes will need to be
present at both client and server sides.

4.5 Data Manipulation and storage


this component is related to encryption issues. The data to be stored is
likely to be sensitive and so the final product must provide a level of security
deemed adequate by current day standards. With this in mind interfaces to
store the data via encrypti
on must be implemented including the reverse
interfaces to retrieve the data.

The component will also help develop the methods required to interact with
the beans containing the data. These allow data to be added or mutated to
keep the records up to date
. Some parts of the data manipulation may involve
design issues of the GUI.

Final Report

SID 199922820

Simon C Milson





Data must be stored in a structured database that is usually accessed via a
server to that database. Statements are created using the database language
SQL that can then be interp
reted by the server. A query to the database can
follow and any return value/s propagated back to the server and back through
the connection to the requesting client.

4.6 Testing

Testing is generally assumed to be an ongoing process in the form of
ing code. Good initial designs will allow for testing to be carried out at
various stages during the coding process to ensure that each module
compiles and executes to a satisfactory level. Testing between modules must
also be used to guarantee each sectio
n of the program behaves correctly.

Debug testing will involve the use of output statements at various points
during execution. The data displayed onscreen at these points will determine
the success of execution. Runtime failures can be pinpointed in thi
s way and
traced back by moving the output statements until the failing line of code is

Command line output requires only the inclusion of the* library and a
call to the System.out.println(<STRING>) method for each line. At server side
this output will need to be logged on screen in an applet. A simple list box
from the java.awt.* library would accept calls using the add(<STRING>)
method. The third method used is to log all output to a log
file. This is
demonstrated in the connection/ser
ver/intelect v1.3 version. This method is
not widely employed in this project as it is deemed easier to have the data
displayed real
time as opposed to having to refresh it on
screen from a file.

Final testing sessions should involve user testing involvin
g subjects of ranging
abilities. It would be nice to allow the user interface to be simple enough for
novice users to navigate but have enough features to keep the expert user
occupied but it is uncertain how many features may be incorporated due to
time c
onstraints. These can always be added in the form of updates.

A testing journal will be maintained to keep a running record of major testing
orientated occurrences within the design of the application. Generally the
journal entry will not be dated as muc
h of the testing is repetitive and
constantly on going. Output combinations may vary each for compilation and
execution as code is edited debug parameters altered to accommodate this.

With this in mind the journal entry should it contain a screen shot or

copy &
paste of output, will only be a snapshot of the state at that current execution.


Final Report

SID 199922820

Simon C Milson





5 Encryption

This section utilises initial research to provide a brief overview of the methods
that are to be implemented in the initial develop
ment of the encryption
components of the project.

5.1 Key Encryption

A simple example of key encryption involves the use of a single key. Both the
User and the client have a copy of the key and can use it to encrypt
messages that can be read by either of


A common standard for secure data transmission is Public Key Encryption.
Public Key Encryption involves the use of a two
part key. The User holds one
part, a private key that is known only to them. The second part, the public key,
is distributed to

the other network clients. The clients can now use it to encode
any outgoing message to the User. Even if the message is intercepted during
transmission it can only be decrypted by the original private key, so it will be
impossible to decrypt without a co
py of that private key.

5.2 Encryption algorithms

Until recently, the standard used to perform encryption on data was the ‘Data
Encryption Standard’ or ‘DES’. This involved using a 56bit encryption key to
encode the data before transmitting. When this met
hod was devised in the
1970’s the DES was sufficient with the technology then available to provide a
practically un
decipherable level of encryption.

Advances in computer technology, while most beneficial in terms of speed
and processing power, brought th
e industry to a stage where it became
physically possible to break a 56bit key. Although the breaking of such codes
is time consuming and costly, it is still viable which renders any files or
connections using DES susceptible to attack from unauthorised so

Triple DES is a method used to improve the DES encryption algorithm. This
involves taking the data stream and applying the algorithm to it three times,
which increases the encryption from the initial, standard 56bits first to 112bits
and then to 1
68bits. This then becomes an extremely secure way of
encrypting data that is adopted by many companies.

The AES algorithm was developed in America to implement 128bit encryption.
This high level of security was deemed to have threatening implications for

the national security of America where it was originally developed and thus its
export has been outlawed for overseas transmission by some countries
including the United States.

Original standard versions of Microsoft Internet Explorer 5.0, the browser
eleased with windows 98, were originally released with only 64 bit encryption
but a later patch was released to upgrade this to a much more acceptable
128bit encryption.

Final Report

SID 199922820

Simon C Milson





Key encryption techniques involve calls to different libraries. When initialising
stances of keys and key factories (for example) we use either RKA or RKSA
as the initialising algorithms. The former is supplied with the standard versions
of the java development studio and supplies weak encryption (
). The latter is a
vailable in the java extension jce and provides much
stronger encryption.

The use of these public and private keys produces the need to secure
storage. The solution is supplied by the use of the keystore class and all of
the supporting classes. This keyst
ore can be manually created and
manipulated using the keytool facility provided with the jsdk distribution.

For the purposes of this project, a secondary GUI tool was used to provide
simple and quick key management. This Java based tool provides all of t
features associated with creating keystores, creating keypairs, importing
certificates, converting keystore types etc.



6 Java Techniques

6.1 Java resources employed


import java.awt.*;

port java.awt.event.*;


import javax.crypto.*;

import javax.swing.*;

import javax.swing.border.*;

Preliminary attempts at coding made use of the 1.4.2_02 release. This
release is an upgrade to previously used Java API’s (1.1.x, 1.2.
x) as the
library and extension upgrades especially in the security areas of 1.4.x were
deemed necessary. This decision was based both on the technical benefits
offered to the project and also to this programmer (for future projects etc).

Ongoing research

into key storage came across reports of bugs in the Sun
Java JRE/JDK 1.4.2.x release. These bugs become significant when
managing keystores. Problems can be seen in the following links. Because of
this it was decided to return to an earlier beta release f
rom sun

the release
1.4.1_7 is currently implemented. Extended encryption JCE policy files were
added to the extensions but for testing purposes, as it is actually illegal to
export these files from the USA

Rather than expend money on high
end Java deve
lopment studio such as
Borland Jbuilder, Microsoft J++ or Borland TogetherJ, it is considered
appropriate to use a simple text editor. For this purpose Notepad, a free editor
supplied with the Windows Operating System is employed. It is also important
Final Report

SID 199922820

Simon C Milson





to n
ote that the studios often incorporate their own libraries and methods into
completed classes increasing portability issues.

A secondary factor in the consideration of design tools is the ease of use. The
applications mentioned in the above paragraph seek

to simplify the design
process through automation of certain tasks and offering smooth interfaces to
perform other, usually complicated tasks. If such a product was to be
purchased, significant training and practice would be required to attain a

enough proficiency level to attempt important aspects of an
important project.

One final note is that the design of efficient GUI’s has already been tackled in
a second year degree module and in many other instances of assessed
coursework. While this com
ponent is important to the project, it is likely that
much of the work entailed would be repetition of application of skills. This may
well see the GUI component often rejected over more important components.

6.2 Object orientated approach

Due to the natu
re of the project, much of the necessary technical no
how is
researched before and as an ongoing process. As the coding becomes more
complex and new avenues are taken, it is necessary to read around the
techniques needed to complete the sections of code.

One attempt to structure the development involves using the jsdk’s object
oriented features. Each different idea can be encapsulated within an object

for example we can create a keystore management object specific to the

This will contain

all of the necessary methods to create and maintain an
instance of a keystore

methods such as loading/saving, updating, comparing
stored items. This is a single identity that can be instantiated and manipulated
for testing purposes. Once this is working

another section can be developed.
Other classes within the application can then use this object to perform the
functionality required for the user.

The functions that the classes perform overlap will regularly require the use of
other completed classes.

This creates a need to develop the classes in
tandem, as one may be needed directly by the other.

Often a stagnant period will occur when one primary area of development
cannot progress until another area has been completed. If time is needed by
the sec
ond for research, as it is an unknown topic, the second becomes the
primary task to be completed in order for the rest of the coding to continue.

This approach of creating application specific implementations of each of the
required standard java objects

allows us to create test objects that can be
queried and used for debugging. It also takes advantage of the object
orientated abilities of java in developing the application in working sections
that can be pulled together by interface classes to provide f
unctionality for the
GUI an the user.

Final Report

SID 199922820

Simon C Milson





6.3 Java Streams

Provision for data input and output in Java is made using streams. Streams
are fed chains of characters or bytes (depending on the type of stream).
Objects in Java that represent data sources that ca
n be changed, can make
use of streams for reading and writing data to that source as needed.

There are two standard abstract classes provided from the ‘’ package

‘InputStream’ and ‘OutputStream’.

The streams can be used when saving data to a f
ile on the hard disk drive. To
enable this we must first create an instance of a file using a string filename,
which we can in turn use to wrap a file stream around to allow data to be sent.

The two lines of code below demonstrate the creation of the two

first the new file and then the new input stream using the file instance.

File inputFile = new File(inputFileName);

FileIntputStream fis = new FileInputStream(inputFile);

Java is an object oriented programming language with which we take t
loosely mean that data manipulation is based around the creation and
interrogation of object classes to retrieve and mutate the data stored within
them. Provision is made to ‘upgrade’ this stream to handle the use of objects,

Objects are slightly more
complicated and require the implementation of
extension classes to handle the object input and output streams.

The FileInputStream instance is used as a parameter for the creation of the
objectStream as above for the creation of the fileStream

the objec
tStream is
‘wrapped’ around the filestream.

The first line of code below demonstrates the creation of the
ObjectInputStream, ois, using the FileInputStream, fis, just created. The
second line gives the method usage require for reading an object from the
When loading objects it is important to note that it is required to inform the
compiler what type of class the object belongs to i.e. in this case the object is
a ‘PersonalDetails’ object and so this is stated in brackets. This method is
known as ‘Ca

ois = new ObjectInputStream(fis);

inObj = (PersonalDetails) ois.readObject();

In order for an object to be converted to and from byte streams for use with
the object stream it must implement the Serializable interface. This needs to
be specifie
d in the class definition

The use of these classes obviously comes with certain overheads.
FileNotFoundException, IOException, ClassNotFoundException are three
exceptions associated with all of the lines of code above that must be caught
Final Report

SID 199922820

Simon C Milson





or propagated u
pwards upon execution otherwise the program is liable to fail
under certain combinations of external environment variables.

These stream classes provide the base functions and interfaces from which
classes with a higher degree of user functionality can b
e extended. Java
provides two classes, ‘CipherInputStream’ and ‘CipherOutputStream’
contained within the JavaX package that extend the usability of the I/O stream
classes to implement data encryption.

6.4 Java Key Management

Keys are indexed using a stri
ng alias that is unique to that key, certificate or
private/public+[certificateChain] pair. The keystore can be manipulated using
method calls from java classes that supply the correct keystore aliases and
passwords (passwords for private keys only).

password provided with a private key is used to encrypt the key before it
is stored in the keytstore. The password supplied to save the keystore is not
used to further encrypt the keystore upon saving. This theoretically leaves the
public keys unencrypted
and visible.

While this may not be conceived as a problem, the design of this application
involves the use of private and public keys with keychains that have all been
validated and signed by the central BBCertificate Authority. It is conceivable
that p
ublic keys could at least assist hackers who wish to compromise the

In order for private/public key encryption techniques to work, the public keys
of every person you wish to initiate communication with must be known. This
will enable data to be
signed with the appropriate public key so that only the
intended recipient can decrypt it.




This inset is taken from a generated self
signed certificate for a BBKeyPair that would
be used to send to a Certificate authenticating body. This would be returned either as
a certificate or certificate
chain signed to validate it by the CA. Extract file


Final Report

SID 199922820

Simon C Milson





6.5 Key Installation

It is necessary when installing the application to include two usable keystores.
The stores should contain a valid key
, private and public (in the form of a
certified certificate containing the public key). These keys can be then be
used by the client and the server when initiating communications. The server
keystore will need to be uploaded to the server before the

server classes can
access it.

It will also be necessary for the keystores to contain a valid copy of a public
key certificate containing the public key of the BBCA. This certificate should
also be signed by the BBCA. This is used during verification of t
he signed jar
file containing the server classes.

There are two methods of creating these keystore files. One is to provide an
installer program that creates two such keystores, name appropriately. The
installer could be as simple as a batch file controll
ed by a class to make use
of the

keytool option but this would require the installation of the java jdk on
the users’ system. The installer should contain methods to create a keypair
and save them to the respective keystores. The second method is to provi
the keystores all ready initiated.

The installation/download speed of the application should not be affected to
any large degree by the chosen method. The former would require additional
classes to be bundled with the software to create the keys and s
ome form of
authenticating the public key with a centralised BBcertifcate authority would
have to be developed. The second would require the inclusion of the actual,
physical keystores. These would already contain a private key and an
associated certificat
e chain containing a certificate with the public key and a
certificate with the public key signed by the BBCA.

6.6 Java File Distribution

When writing in many programming languages it is usually the norm. to
produce a pre
compiled, executable file from th
e programmed code for
distribution (e.g. c++). In contrast to this and to allow for its impressive
portability, the Java programming language is implemented as an interpreted
language. Any system with a suitable Java interpreter installed can execute a
a class file regardless of the system type or O/S (however some features
may vary slightly in action and visual appearance depending on this).

Java applications will generally be composed of many classes, linked together
as a package. This may also inclu
de input files and output files such as
parameter files and keystores. An application can be deployed simply as this
set of classes and files but another issue arises when the application is
designed to run as an applet.

Applets operating within the sandb
ox have strict restrictions preventing
actions such as IO and socket access. In order to identify trusted applets and
allow such applets permissions to perform such tasks, Java makes use of two

policy files and jar files (short for Java Archive fil

Final Report

SID 199922820

Simon C Milson





A policy file defines the required code
base and then sets out the permissions
and access rights to the different resources that the code
base utilises. The
file will also define a keystore and a public key certificate, identified by its


multitude of files that make up a java application can be grouped together
and stored in the form of a jar file. A jar file is created using the command line
jar tool provided with the standard editions of the Java API. The jar file alone
provides an exce
llent distribution format that, along with an associated policy
file can be integrated simply into html web pages.

Java provides an extension to this however that provides improved
authentication when using applets over the Internet. The jar signer tool,

provided as standard, allows the digital signing of a jar file using a private key.
A copy of the associated public key certificate is attached to the jar file. This
can be compared to a copy of the officiating certificate that is known to be

6.7 Java Database Access

Object Oriented programming allows the creation of encapsulated objects that
can hold data relating to some idea. When relating this to data storage this
becomes a useful concept.

An Object Relational database (ORD) can be

perceived as a set of tables and
manipulated in accordance with the relational model of data. It contains a set
of objects used to store, manage, and access data. Examples of such objects
are tables, views, indexes, functions,

(ORD)’s can make use of suc
h objects when defining fields. Rather than
entering individual fields in the database for each aspect of a person

name, surname, age, address etc, we can create a person object that
encapsulates all of this information. ORD field types can be spec
ified as these
objects thus allowing many instances of these objects to be stored.

FirstSQL is a ORD written purely in Java for use with Java. This provided an
influencing factor when searching for Java ORD’s. As long as the appropriate
database connector

is used and an appropriate Java interpreter can be
located on the system, the entire, Java
based application should be
completely portable.

FirstSQL requires installation within the users home directory. Execution of
the setup interfaces (command line an
d GUI) requires the further setup of a
number of property files to identify each particular instance of the database
and database server programs.

Final Report

SID 199922820

Simon C Milson





In order to define new object types in a designated FirstSQL database it is
first necessary to create th
e object java file and compiled class file (e.g. the
person object class).

SQL statements can be constructed to retrieve these stored instances in
much the same way as base type records would be retrieved. This powerful
tool allows complex objects to be

created and manipulated in java and stored
simply within the database.

SQL is a standardized language for defining and manipulating data in a
relational database. In accordance with the relational model of data, the
database is perceived as a set of tabl
es, relationships are represented by
values in tables and data is retrieved by specifying a result table that can be
derived from one or more base tables.

SQL statements are executed by a database manager. One of the functions
of the database manager is t
o transform the specification of a result table into
a sequence of internal operations that optimize data retrieval. The
transformation occurs in two phases: preparation and binding.

All executable SQL statements must be prepared before they can be
ed. The result of preparation is the executable or operational form of
the statement. The method of preparing an SQL statement and the
persistence of its operational form distinguish static SQL from dynamic SQL.

Java OBDC Connectivity

It is necessary to b
ridge between Java method calls and the execution of sql
statements by a database manager.

We can make use of a Database Connector/ODBC: This lets you connect to a
MySQL database server using the Open Database Connectivity database
programming interfaces o
n all Microsoft Windows and most Unix platforms,
including Linux, Sun Solaris, HP
UX, IBM AIX and Mac OS X

MySQL Connector/J: This is a native Java driver that converts Java Database
Connectivity calls into the network protocol used by the MySQL database.
lets developers working with the Java programming language easily build
programs and applets that interact with MySQL.

6.8 Ethical


This section presents a chance to develop ideas regarding the outside worlds
input into the project development

When developing user end application
software it is imperative that the design process try to consider as many of the
infinite external factors that could influence the political, moral, legal
standpoints of the design and of the application.

Final Report

SID 199922820

Simon C Milson





It enables

an out
box, birds
view angle that enables these factors
to be detailed and assessed in an abstract fashion, often with suggested
methods of approach.

Style: subjective analysis of the ethical issues surrounding the project

When dealing with i
nformation of such a sensitive nature, it becomes readily
apparent that the amount of pitfalls that occur when dealing Internet could
become overwhelming. While SSL provides excellent secure communication
and is available as an extension to the jsdk, it wa
s decided to set up the
encryption process manually.

It was thought more appropriate in terms of project depth and in terms of
providing an understanding of the underlying methods involved in creating
and managing secure communications.

The fundamental

requirements of secure communication (generally, and
within the use of this application) rely on the use of secure private keys and
distributed public keys. This statement alone creates a whole host of
problems involving secure creation, storage, accessib
ility, transmission, and

And these are just at the fundamental level.

These keys rely on ciphers created by algorithms of which there are various
currently available of varying strengths and efficiencies.

One interesting concept to deal w
ith when considering algorithms is the
theoretical relationship between the current acceptable strength and the
computer processing power currently available. A needed fact is that an
algorithm is just that, a complicated algorithmic calculation performed
on a
stream of bits to make it unintelligible. This basically means that given time
and enough computer power it could in theory be cracked.

The time variable cannot be changed. Time is, currently, constant. The power
variable will however invariably inc
rease given time. This increase is unlikely
to be constant and computing power increases over the probable two years
taken to produce a new version may be significant.

The encryption must be of strength, at least deemed acceptable by current
browser stand
ards and preferably higher industry standards. These are
supplied with development packages but strengths cannot be guaranteed in
all versions of all browsers

especially in older or more obscure examples.

It is necessary to bear in mind that for the onl
ine interface, the connection to
the server could well be made over county and international borders. The
security cannot be guaranteed within the neighbourhood let alone over these

When dealing with the transmission of credit card and bank det
ails etc, it is
not enough to rely on the secure connection alone. The application should
Final Report

SID 199922820

Simon C Milson





incorporate message encryption and validation to ensure no tampering occurs
during transit.

6.9 Java security issues

While java itself is intrinsically a secure envi
ronment it is still not infallible.
The installation of the most recent releases on all machines executing java
scripts, applets, applications etc, should provide the most secure running

This is an ideal situation that does not often occur. One i
dealistic solution
would be to ship the latest release with the application. CD distribution would
only leave the obvious problems of installation size on disk and installation on
the server. Online distribution creates the added overhead over bandwidth

This said there are still known ‘holes’ within java that could be exploited by
intruding third parties under certain circumstances. Unfortunately with the
enormity and intricacy of the Internet and operating software, there will always
be the presen
ce of security issues that need to be addressed.

Java incorporates an interesting line when running applications in web
browsers. Java code is executed (aside from scripts) in the form of small,
compiled classes called applets. These applets potentially
have access to
many hazardous system operations, which poses a problem when trying to
write applets to run on a visitor’s machine.

It is possible to make sure only secure applets run, but still allow unsecured
ones some measure of execution to allow for
all types of interaction.

Java handles this by using a concept known as the sandbox. This is a secure
holding area to which applets can be downloaded. In order to run applets that
have more functionality we need to verify that an applet is secure. For thi
s to
succeed its certificate must be validated by a recognised CA, (or certificate in
its chain). Successful validation allows these applets pretty much their normal
control (although levels of execution can be set).

Failure to produce a certificate that

can be validated, or failure to accept the
certificate, causes the applet to be run in a limited mode within the sandbox.
This is an attempt to improve security against system damage by malicious

This introduces a new variable to consider in the

form of ensuring the classes
powering the user end of the online interface communication have the
required certificates to run on the users computer. This may have to be
initialised at installation of the client program with the required
ority certificate being added to the installed browser.

Final Report

SID 199922820

Simon C Milson





7 Code Journal

Style: subjective analysis of the attempts made at coding the design.

Initial ideas

As coding has progressed, various methods are used and developed further
or temporarily discarde
d. Originally the database methods and object stream
encryption code were all placed within a single class for ease of editing
through early research.

Current ideas tend towards implementing the data manipulation ideas
previously exampled in code from ye
ar 2 projects to enable the database to
be stored as a single entity rather than the individual objects. This should
hopefully save on disk processing time and aid in the use of encryption.

In order to do this the database is defined in a separate class
so as an
instance can be made. This instance can be manipulated to provide
functionality to the database classes. It can then be passed through the
required encryption methods before finally being placed on object output
stream to be saved to the specified


This does present security issues in so far as the database will have to be
loaded into memory as a whole. If it is stored in an encrypted form then
whenever a call is made to the database it will need to be decrypted for
successful completion.

he alternative is to decrypt the database upon loading and place it in
memory in this decrypted format. Although this should save on processing
time it does present certain security issues. Unless it is certain that the system
the program is being used on
is secure system then it is possible that the
memory could be read by external sources.

It was decided to store all of the public keys (should there be multiple keys) in
a store on the users hdd. The store would be implemented using encryption to
the keys cannot be accessed. This would mean that a further key
would need to be saved by the user to access the keystore be it in a file or
written on paper.

To begin with, the saving functions are written into an object class that
extends the vector pac
kage. This package allows the storage of objects

keys in a vector. The class, KeyStore can be instantiated to take advantage of
these vector properties plus any others that are written into the KeyStore
object. This would indicate that the KeyStore
class will need methods to load
and save itself when instantiated.

These methods will also need to implement the encryption features. They key
for encryption is passed into the KeyStore object so has to be generated by
the class that is manipulating the

Final Report

SID 199922820

Simon C Milson






Subsequent research found that there was a widely recognised method of
storing keys effectively on permanent medium. This is achieved using
keystores and makes the previous design redundant. The keystores provide
satisfactory levels of

encryption while the keys are stored and access to
private keys is controlled through a keystore password (see section 7
subsection ‘Java security issues’ for keystore elaboration).

Keystore management can be controlled purely from java classes by creat
situation specific implementations of the methods in the keystore class
provided in the package. In theory it should be possible to create
new instances of a BBKeystore and perform various key/certificate functions
on it before saving the

changes to disk.

The research and development of the keystores presented a multitude of
problems that were especially evident when trying to gain access via an
applet. section 9 subsection ‘java keytool’

Class Diagram



creating the init
ial set of beans that will be used to represent the
data while it is manipulated by the program. The standard storage method for
objects employed within this project will make use of the java.util.Vector
package which allows objects to be stored in an stru
cture similar to an array.
The objects can be easily manipulated and read from these for processing or


added the relationships to the beans and the cardinality’s.
These represent the number of instances of a particular object may b
referenced to another particular object at any time.


modified the beans to include accessors and mutators to allow
for bean functionality. Began implementation of the vetoableException classes
to allow data checking which will prevent a be
an entering an invalid state.

When we add methods to verify inputs before actually changing the beans
data the beans become self=contained. Objects may register an interest in the
beans listener object


After reading online papers regardin
g the use of serialization to
transfer objects to data streams without first converting them into byte arrays,
it was decided to update all current beans to implement Serializable. This will
allow these features to be made use of when the objects are to be

sent to the
cipher streams for encryption.

Final Report

SID 199922820

Simon C Milson







Initial attempts made using examples from the internet and from
java in a nutshell as reference to create compilable code that will create a
URLConnection object to receive informat
ion from a web based server =
unsuccessful. Attempts begun to create a socket object that will be of more
use when it comes to data transfer with streams.


creation of a demonstration class that takes an object, and a
filename and can perform
save and load routines on those input variables.
This provides a working demonstration of the basic use of streams to transmit
data in java.


the period from this date up until the Christmas break will be
used for the development of the encryp
tion classes that will allow the data to
be stored and transmitted securely. This involves the creation of an object
cipher stream that can be used to output either to a file or to a secure socket
connection stream.


Attempts are being made to cre
ate instances of ciphers and the components
that are needed to initiate a working cipher for use with the object streams.
The components are to be stored in individual object classes that can be
instantiated with the component as a variable of the object.
Variables are
made private so must be manipulated using accessors and mutators with the
information stored never actually being
accessed directly.

Initial compilation attempts created the usual sy
ntactical errors and issues
relating to method calls. Debugging the code created an initial working model
that should in theory return a usable cipher to wrap around the object stream
providing encryption. Attempts to run it produce multiple exceptions. Fu
debugging isolates the lines causing the exceptions and identifies them
problem. Calls are being made to variables that should have been initialised
to certain values but for some reason they have not. This problem has
currently not been solved, as a
ll of the preceding lines appear to be correct
syntactically and appear to have been used in the correct context.


a breakthrough occurred with the cipher coding. A simple error while defining
InitiateCipher object was not allowing the correct instantiation of the object
when the constructors were called. A simple changed solved this and the rest
of the coding proved accurate as the correct InitiateCipher objects are now
created with the cipher
details and algorithm details are now displayed.

With these classes we have developed the bases for the encryption of
streams using ciphers.


Final Report

SID 199922820

Simon C Milson





Coding work was temporarily reduced as the two
week period previous to this
date had to be used for
other essential university work including assignment
finishing and exam preparation/sitting.

The next stage in the coding process involves the incorporation of these
cipher classes to produce a key pair that can be used in public
private key
The encryption will be used to provide safe storage and
management of these keys on the host computer. The server will also have a
similar setup to store its own set of keys.

These key pairs can be used to for two purposes

to verify that the
ta is from the stated source and to decrypt the data. The server
will have a copy of the client’s public key saved in its key store. If a message
is sent to the server that is encrypted using the client’s private key, only a
copy of its public key will suc
cessfully decrypt the message. This satisfies the
two purposes.

These messages are sent over the Internet via a secure connection using
SSL (Secure Socket Layer).


Both the client and the server will have there own specific IP address at that
stance of communication (this will have to be checked each time connection
is lost in the case of dynamically assigned IP numbers). This information will
need to be retrieved and stored by an object class. For testing on the server,
the class can be run as

an applet initially to generate a visual test of the local


It is at this stage decided that the comments made on the 18/12/03 regarding
the creation of keys are to be changed in favour of the use of BBkeystores
and the easy creation of rel
ated keypairs using keyfactories.

The keytool facility provided with java is extremely useful when setting up
keystores. To create a new keystore simply enter the correct syntax to create
a new keypair and at the

keystore tag enter the name of the new s

A batch file was created to create a new key, add it to a new keystore and
create a self
signed certificate of the public key that could be used in
communication verification. The new keypair was saved as a private key with
a certificate containing

the associated public key stored with it. Access to the
private key is secured with a key password. To secure the keys further, the
keystore itself is also controlled by a keystore password. For testing purposes,
all passwords for keys and keystores throu
ghout the project are set to the
value ‘intelect’.

Problems were encountered when attempting to load and save the
BBkeystores to the hard drive. IOExceptions prevented the successful loading
of the BBkeystore for compilation.

Final Report

SID 199922820

Simon C Milson





There were found to be two

errors, the first is shown in the screen dump in the
testing section. When a keystore is defined it must be defined as a keystore
file. The original file did not have this extension and thus loading failed.

The java class should be able to load an insta
nce of this keystore for editing
however the exceptions still occur. The cause was found to be an incorrect
definition of the required encryption technique. The keystore is created by
keytool using the weaker JKS encryption however the class was attempting

use an instance of keystore initialised using the stronger encryption.

Changing the class and recompiling produced successful results in the correct
loading of the keystore. However there is still a problem in so far as the use of
the weaker security

methods to store the keys and keystore.

Intelect Server


Basic BBIntelect server Version 1.0 design attempts

Concentrating on creating classes that at the client end, request and setup a
connection and at server end, listen and establish the

connection. Connection
attempts are being made locally with the server connection listening on port
its test port 5000. Early attempts to establish connections across the local
area network met with failure, possibly attributable to firewall/proxy restric
in force.


BBIntelect server design attempts Version 1.1

While a secure connection ensures that any eavesdroppers that manage to
retrieve the data only gain encrypted nonsense, it does not prevent the
eavesdropper from altering that data to

produce incorrect, malformed
operations at the server or client ends. The aims of the first version of
BBIntelectServer are to produce a working client/server relationship with
recognisable protocols that works using an encrypted connection and
provides s
ender authenticity.

This attempt succeeded in producing a server program that again opened a
listener on port 5000 to wait for incoming connections. The client program
also compiled correctly but failed at runtime due to restrictions over firewall
eges in force at the university campus. Hopefully this will be resolved for
future testing purposes.

The aim of this was to successfully create a signed object that could be
serialized and transmitted over a secure connection to be checked at the end

integrity. After more research it was decided to pursue the branch of using
a signature for the data rather than actually creating a signed object. The
encrypted stream accepts only byte streams or blocks of bytes thus it is
Final Report

SID 199922820

Simon C Milson





simpler if the whole message w
ith signature is stored as a byte [] for


Version 1.2

The server and client programs each need access to their own
set of keys and certificates. The keys saved on the server are, the servers
own personal private key and a list of a
ll of the public keys it knows in the
form of x509 certificates.

A public key certificate corresponds to a copy of the client program thus if u
have a copy at home and a copy at work the server will save a certificate for
each of these copies.

The clien
t on the other hand need only store its own private key and the public
key certificate relating to the server. This obviously relates to the fact there is
only one copy of the server. No interaction is allowed between copies of the
client to help aid secur
ity and unauthorised access. (This may change if we
allow the use of multiple copies of the server and database

say for backup

Large degrees of research into this area were needed to understand the
correct methodology in use on the Internet a
t the moment with regards to
public/private key encryption, digital signatures and certificates & certificate
chaining. The classes developed as a result of this allow the instantiation of
the relevant providers and initialisation of the relevant objects n
eeded. This is
coupled with a bean object to hold instances of the key and certificate details.

For testing purposes the certificates were also created and tested using two
batch files and the Java

keytool facilities.


Version 1.3

a rewritte
n client interface provided command line setup of the
client connection and the transmission of a byte stream across the
connection. No form of encryption is incorporated at this point. Server side
control is established through an applet, accessed via a s
imple html script.
The applet provides two buttons to activate and halt the server. A dialog box
records server activity for debugging purposes.

At this point the parameters for server connection are hard coded whereas the
clients are set at runtime. In
future versions the parameters will be loaded
from a file.

Once the applet loads in the html page, the server connection must be
initiated using the start server button. Appropriate dialog indicates connect
success and the connected port. The client progr
am is run from the command
line and allows the connection parameters to be established manually. For
testing purposes a string is sent down to the socket and on down the stream
as a byte stream. The server reads the individual bytes into an array with the
byte values displayed in the dialog box.

Final Report

SID 199922820

Simon C Milson