dss 12 s4 03 design specification

7/29/2019 DSS 12 S4 03 Design Specification

1/48

School of Computer Science & Software Engineering

Bachelor of Computer Science (Digital Systems Security)

CSCI321- Project

Design Specification27 February 2013

Group: SS12/4B

Khoo Jun Xiang 4000766 [email protected]

Ang Wencan Stephen 4194032 [email protected]

Goh Kheng Siang Joel 4187490 [email protected]

Lim Sing Hui 4185948 [email protected]

Low Jia Hui [email protected]

Supervisor: Mr Sionggo Jappit

Assessor: Mr Tan Kheng Teck
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/48

Design Specification [SS12/4B]

Page 2 of48

Document Control

Title: Design SpecificationDocument Name: Design Specification

Owner Current VersionLast Change on

Approved byDate Time

Khoo Jun Xiang V1.5 27-Feb-2013 8PM Project Manager

Distribution List

Name Title/Role Where

Mr Sionggo Jappit Supervisor SIM-UOWMr Tan Kheng Teck Accessor SIM-UOW

Khoo Jun Xiang Project Manager SIM-UOWLow Jia Hui Software Architect SIM-UOWGoh Kheng Siang Joel Test Designer SIM-UOW

Lim Sing Hui UI Designer SIM-UOW

Stephen Ang Database Designer SIM-UOW

Record of Revision

Revision Date Description Section Affected Changes Made byVersion after

Revision

10/12/2012 Document Creation- Briefing and

assign tasks

All Khoo Jun Xiang 0.1

12/12/2012 Added all section. A draft of proposal. All ALL 0.2

13/12/2012 Added Document Preview, ProjectOverview, Project Scope

Introduction Khoo Jun Xiang 0.3

13/12/2012 Added System Architecture, Detailed

Components, Modules Design

System Design ALL 0.4

15/12/2012 System Architecture Component System Design Lim Sing Hui,

Stephen Ang

0.5

15/12/2012 Produce Use Case Diagram Modules Design Low Jia Hui 0.6

16/12/2012 Produce Activity Diagram and

explaination, ERD

Modules Design Goh Kheng Siang,

Jia Hui, Jun Xiang

0.7

17/12/2012 Produce Sequence, State Diagrams Modules Design ALL 0.8

17/12/2012 Design User Interface Modules Design Goh Kheng Siang 0.9

18/12/2012 Update of Diagram Modules Design,

Sematic Data

Khoo Jun Xiang 1.0

18/12/2012 Design Database Database Design Stephen Ang

20/12/2012 Update on Design User Interface Sematic Data

Model

Goh Kheng Siang 1.1

20/12/2012 Update on all Diagrams Modules Design ,

Sematic Data

ALL 1.2

27/12/2012 Final Review - Preliminary ALL ALL 1.3

15/02/2013 Update on diagrams ALL Lim Sing Hui 1.4

27/02/2013 Finalize the document ALL Khoo Jun Xiang 1.5


3/48


Page 3 of48

Contents................................................................................................................................................................... 1

Document Control ..................................................................................................................................... 2

1. Introduction ........................................................................................................................................ 4

1.1. Document Preview ...................................................................................................................... 4

1.2. Project overview ......................................................................................................................... 4

1.3. Project Scope............................................................................................................................... 4

2. Systems Design .................................................................................................................................. 5

2.1. Systems Architecture .................................................................................................................. 6

2.2. Detail Components / Modules Design ...................................................................................... 11

2.2.1. Use Case Diagram ................................................................................................................. 11

2.2.2 Sequences Diagram .................................................................................................................... 12

2.2.3 Activity Diagram ........................................................................................................................ 22

2.2.2 State Diagram ............................................................................................................................. 32

2.3. User Interface ............................................................................................................................ 34

2.4. Semantic Data Model ................................................................................................................ 39

2.5.Database ......................................................................................................................................... 40

1. Appendix .......................................................................................................................................... 48


4/48


Page 4 of48

1.Introduction1.1.Document Preview

Design Specificaion is used to explicit information about the requirements for a product and how the

product is to be put together. It is organized in the format that introduces the project overview and scope.

Followed by the System Desgin which includes System Architecture, Design Componets/Model Design,

User Interface and Semantic Data Model. More details of each component of System Design will be

covered in their respective sections.

1.2.Project overviewThe task is to developing the DB-Wrapper, a database wrapper that protects against inference attacks on

statistical database. The software provide as a filter in the connection between the user application and the

database to verify if the query compromised the confidentiality of the system. The software has a two

layer hierarchical structure which allows dynamic setting up of the Database Wrapper.

1.3.Project ScopeThe DS-Wrapper is intended to work as a query-filter like process that filters out the queries that are not

allowed. The wrapper will act as a inference protection mechanism to protect the statistical database

against disclosure of confidential and sensitive information and applicable on ORACLE-express edition

10G. As part of the project, the wrapper will provide Query Restrictions, Systematic Rounding, Query set-

size control and Auditing to prevent inferences attack. This will provide data confidentiality and integrity

to the database.


5/48


Page 5 of48

2.Systems DesignThis section describes how the DB-Wrapper is being implemented and how it interacts with the Client

Application and the statistical database. The following diagram below explain the structure and use of theDatabase Wrapper.

The user have to be first authenticated to the Statistical database (Oracle XE 10g) and when user are to

make a query to the statistical database query it will be passed through the database wrapper and verified

if it is a possible inference attack. If inference attack occurs the query will be rejected and stored under

inference history and query result will not be return to the user, else the result will be return in a Range

format or systematically rounded.


6/48


Page 6 of48

2.1.Systems ArchitectureOur project employs a 3 Tier Architecture approach. It consist of Presentation, Logic and Data Tiers.

Presentation Tier consist of the user interface. Interaction with stakeholders/ clients will be held in this tier.

The role of this tier is to translate the request and results from stakeholders/ clients to something

understandable. Logic Tier is in the middle of the 3 tiers. Logic Tier moves and process data between the

other tiers. For example, Logic Tier will inform the Presentation Tier what is to be displayed. And tells the

Data Tier what is to be retrieve within the storage. Meaning to say, Logic Tier process commands, and

makes decisions and evaluation for the software. This is the tier where all the processing data is achieved.

Lastly, Data Tier is where data are stored and retrieved. This tier can only be interacted through the Logic

Tier by the use of SQL commands. Diagram below would explain the 3 Tier Architecture in an more

abstract form.

3 Tier Approach:

Source:http://edn.embarcadero.com/article/images/10343/3tier.gif

First/Presentation Tier consist of Graphic User Interface, and would be covered in 2.3 User Interface

section of this document.
http://edn.embarcadero.com/article/images/10343/3tier.gifhttp://edn.embarcadero.com/article/images/10343/3tier.gifhttp://edn.embarcadero.com/article/images/10343/3tier.gifhttp://edn.embarcadero.com/article/images/10343/3tier.gif


7/48


Page 7 of48

Second Tier Approach

Second/Logic Tier illustration would consist of Process-Flow, Data-Flow, State and Transition. Tools

such as Process-Flow Diagram, Data-Flow Diagram, State Diagram, Transition Diagram, Use-cases.These will be covered in the 2.2 Details Component/ Modules Design of this document.

Three main techniques are used in second tier approach.

1. Conceptual Approach: Lattice ModelIn Second Tier for application server, our team used conceptual model that provides a framework to

investigate the security problems at the conceptual-data-model level. One of the popular approach in

conceptual model is lattice model. This model represents a framework for greater investigation of

statistical database security problems although it gives many constraints for users. The lattice model

relates to statistical database information in tabular form with different levels of aggregation. Metadata

modeling/Data dictionary is used to implement Lattice model. Metadata modeling is similar to lattice

model and with used of fet-size control that elimates chances of inference attack.

Source:

http://dsns.csie.nctu.edu.tw/ssp/paper/29.Information%20Protection%20in%20Dynamic%20Statistical%20Databases.pdf [page

4]

To illustrate, a sample of lattice was given above. The database has attributes of Age, Gender and Position(A, G, P). The detailed way to show this database is in tabular form which consist of a three-dimensional

table AGP.
http://dsns.csie.nctu.edu.tw/ssp/paper/29.Information%20Protection%20in%20Dynamic%20Statistical%20Databases.pdfhttp://dsns.csie.nctu.edu.tw/ssp/paper/29.Information%20Protection%20in%20Dynamic%20Statistical%20Databases.pdf


8/48


Page 8 of48

Below shows report generated by the attice models. A, G and P represent Age, Gender and Position

respectively.

Source:

http://dsns.csie.nctu.edu.tw/ssp/paper/29.Information%20Protection%20in%20Dynamic%20Statistical%20Databases.pdf [page

4]

Lattice model has been proved to be a powerful and effective model for analysing inference problem andto come up with solutions. In transactional database system, the number of entries can be either zero or

any number of records stored in database. Therefore, it is possible to infer that protected information can

be put together as the results of several statistical queries into session. Every query returning non-individual results is expected in the behaviour of statistical queries. Therefore, they are not revealing data

with single records.
http://dsns.csie.nctu.edu.tw/ssp/paper/29.Information%20Protection%20in%20Dynamic%20Statistical%20Databases.pdfhttp://dsns.csie.nctu.edu.tw/ssp/paper/29.Information%20Protection%20in%20Dynamic%20Statistical%20Databases.pdf


9/48


Page 9 of48

Query restriction methods imposed extra restriction on queries which includes restricting the query set

size, controlling of the overlap among successive queries, auditing, partitioning and suppressing cells.

Some of the methods cannot guarantee high security assurances while others also limit usefulness of the

Statistical Databases. The team uses Query-Set-Size-Control method for this approach.

2. Query-Set-Size-Control method:It is worked by setting upper and lower bounds for the size of the query that is based on the properties of

the database and on the preferences fixed by the database administrator. When the number of returned

records did not lie within these bounds, the information request is rejected and query answer is denied.

For each query, this method can restrict the number of individuals |C|. The database system respond to the

query answer only if |C| satisfies the condition.

K: lower limitC: result size

L: size of database

K: parameter set by the database administrator.

KC L K

L is the size of the database ( number of individuals represented in the database) and K is a parameter set

by the database administrator. K should satisfy the condition.

0 KL/2 ,

otherwise no query can be answered.

Main advantage of query-set-size control method is easily implemented so that this scheme is suitable fordynamic Statistical Databases.


10/48


Page 10 of48

3. Restrict Non-Aggregation QueryGUI of DB-Wrapper is implemented in a way that only aggregate function are allowed.

Combining the 3 techniques above, DB-Wrapper is able to prevention four different types of inferenceattacks. Arithmetic Means(infer size), Single Match, Addition Aggregate and Partitioning.

Arithmetic Means: When computing the average of a field, table size must vary the attributes of averagecomputation. This is the beginning of the several inference attacks. The arithmetic function considered as

important and secure because they could not compromise individual data.

Single Match: It is a successful method for usage of queries matching exactly one data item. This method

enable to access data pertaining to those reduced groups by creating queries which match the records wewant to disclose and include other conditions that disguise the real intention of the query.

Addition Aggregate:This attack implements SUM aggregrate to infer a value from a reported addition of records.When

generating a query Q1 which returns N as the total SUM on a field of a data table, second query can becreated with the value N to disclose information about a particular entity within system. When SUM on a

field is M, the difference between N and M produces a value which is not stored on database and can be

used to infer restricted data.

Partitioning:

Statistical databases hide data when a small number of entities makes a large proportion of the datarevealed. Hence, the attacker able to locate desired data by using multiple queries which gives minorresults. The attacker will combine additional records to retrieved other different aggregate queries.

Third/Data Tier in our project would be in the Oracle SQLite database which we will implement towards

the end of the project. Our project will be using SQLite as the embedded database in our program. SQLite

Manager/Browser will be used to manage the SQLite database in the computer. These will be covered in

the 2.2 Details Component/ Modules Design of this document.


11/48


Page 11 of48

2.2.Detail Components / Modules DesignUML diagrams will be used to specifies and defines services of DB-Wrapper.

2.2.1. Use Case DiagramFollowing use case diagram is extracted from requirement specification document. This diagram will

describes the main functionality provided by DB-Wrapper in actors point-of-view, their goals represented

as use cases, and any dependencies among those use cases.

Note: Textual Descriptions of the above use cases are written in requirement specification document.


12/48


Page 12 of48

2.2.2 Sequences Diagram

Following UML sequences diagrams will act as process flow diagrams to provide the project team with a

dyamic view of the flow of messages, events and actions between the objects or components of DB-

Wrapper. Sequence diagrams for main use cases were drawn as shown below.

UserLogin


13/48


Page 13 of48

UserCreate Report


14/48


Page 14 of48

UserView, Delete Report


15/48


Page 15 of48

User Export Report


16/48


Page 16 of48

Administrator - View Log Files


17/48


Page 17 of48

AdminstratorManage Application


18/48


Page 18 of48

AdministratorManage Constraint


19/48


Page 19 of48

Administrator - Manage Range


20/48


Page 20 of48

AdministratorManage Roles


21/48


Page 21 of48

AdministratorManage Users


22/48


Page 22 of48

2.2.3 Activity Diagram

Following UML activity diagrams will show the workflows of actions done by user throught the user

interface with support for choice and iteractions. It provides project team members with views of the step-

by-step workflows of component in DB-Wrapper system. It also shows how the user interface reacts in the

flow of the activity.

UserLogin


23/48


Page 23 of48

UserCreate Report


24/48


Page 24 of48

UserView, Delete and Export Report


25/48


Page 25 of48

AdministratorView Log Files



26/48


Page 26 of48



27/48


Page 27 of48

AdministratorManage Range


28/48


Page 28 of48

AdministratorManage Roles


29/48


Page 29 of48

AdministratorCreate User


30/48


Page 30 of48

AdministratorUpdate, Delete User


31/48


Page 31 of48

AdminManageApplication

Note: SQL commands are executed.


32/48


Page 32 of48

2.2.2 State Diagram

Following UML state diagrams are used to provide the project team with abstract description of the

behavior of the system. It shows and decides what an object should do when a message is received. We

will be analyzing the states of DB-Wrapper system, User and Query object classes. Different states of

these object will be tracked throughout the system.

Query


33/48


Page 33 of48

User

DB-Wrapper


34/48


Page 34 of48

2.3.User InterfaceInterfaces among the sub-systems and other external systems will be described in this section. Below

structure shows the basic breakdown of the interface design of DB-Wrapper. Structure might be expanded

if there is sufficient time for the project team to implement more features. Once the user or an

administrator has logged in, they will be directed to their respective page for a normal user or an

administrator. They will then be able to perform the functions that are on their respective menu.

DB-Wrapper

Admin

View

Logfiles

Manage

Range

Manage

Application

Manage

User

Manage

Role

Manage

Constraints

User

Create

Report

View

Report

Export

Report

Delete

Report


35/48


Page 35 of48

Login page will be displayed to users at the beginning of the program. Users will be prompt to enter their

username and password. Login information will then be validates and matches against the information inthe database. DB-Wrapper will then determine whether the user is a normal user or administrator and theywill be directed to their respective pages (User or Administrator)


36/48


Page 36 of48

Login user will be directed to their respective page based on their role indicated in the database upon login.

Interface for Normal Users is shown below. Normal user can only create report and view report. The

screenshot below shows the Create Report Tab.


37/48


Page 37 of48

The screenshot below shows the View Report tab. The report can be delete if unwanted.

Page Description

Create ReportTo make queries, create/generate report and save report in database.

View ReportTo view report together with the option to delete or export (txt or xls).


38/48


Page 38 of48

Below shows the interface for Administrator. The six different tabs are View Log, Range, Application,

User, Role, Constraint.

Page Description

View LogView log file based on the username indicated

RangeDefine the minimum and maximum range of attributes.

ApplicationEnter a correct database and select the table with the attributes to read in meta-data

successfully.

UserCreate, update or delete a user from database of DB-Wrapper.

RoleCreate, update or delete a role from the database of DB-Wrapper.

Constraints - Create, update or delete a constraint from the database of DB-Wrapper.

Note: Screenshots of other pages can be found in the user manual.


39/48


Page 39 of48

2.4.Semantic Data ModelIn this section, UML class diagram is used to describes the object and information structure of our

product application. Our project analysts will make use and reference to it throughout the software

development cycle. Entities and relationship among them are identified in the system.

Top Part of Class Diagram


40/48


Page 40 of48

Bottom Part of Class Diagram

Note: To help in reading of the class diagam, a JPEG image file of the class diagram is included in

softcopy submission.


41/48


Page 41 of48

2.5.Database

Below shows the conceptual model of DB-Wrapper inference protection database. It consist of user, roles

and data dictionary (metadata repostiory). Instead of directly accessing the application database, user will

access the data dictionary.


42/48


Page 42 of48

Relational Database Description of inference protection database.

Application (AppNum, AppName)Primary Key: (AppNum)Attribute (AppNum, TableNum, AttributeNum, AttributeName)

Primary Key: (AppNum, TableNum, AttributeNum)

Foreign Key: (AppNum, TableNum) REFERENCES [Tables (AppNum, TableNum)]

Constraint_Associate (ConstraintNum, AppNum, Value)

Primary Key: ConstraintNum, AppNum

Foreign Key 1: ConstraintNum REFERENCES [Constraint(ConstraintNum)]

Foreign Key 2: AppNum REFERENCES [Application(AppNum)]

Constraint (ConstraintNum,CostraintName)

Primary Key: (ConstraintNum)

Range (AppNum, TableNum, AttributeNum, RangeNum, Label, Mininum, Maxinum)

Primary Key: (AppNum, TableNum, AttributeNum, RangeNum)

Foreign Key: (AppNum, TableNum, AttributeNum) REFERENCES [Attributes(AppNum,

TableNum,AttributeNum)]

Report (ReportNum, ReportName, UserName, AppName, ReportAddedDate)

Primary Key: (ReportNum)

Foreign Key: (UserName) REFERENCES [User( UserName)]Foreign Key 2: (AppName) REFERENCES [Application(AppName)]

Candidate Key: (ReportName)

Report_Query (QueryNum, ReportNum, ReportName, ReportCategory, Data)

Primary Key: (QueryNum, ReportNum)

Foreign Key: (ReportNum, ReportName) REFERENCES [Report(ReportNum, ReportName)]

Report_Table (ReportNum, ReportName, TableUsed)

Primary Key: (ReportNum, TableUsed)Foreign Key: (ReportNum, ReportName) REFERENCES [Report(ReportNum, ReportName)],

Foreign Key 2: (TableUsed) REFERENCES [Tables (TableName)]

Role_Associate (AppNum, TableNum, RoleNum, Association)Primary Key: (AppNum, TableNum, RoleNum)

Foreign Key 1: (AppNum, TableNum) REFERENCES [Table (AppNum, TableNum)]

Foreign Key 2: (RoleNum) REFERENCES [Roles (RoleNum)]


43/48


Page 43 of48

Roles (RoleNum, RoleName)

Primary Key: (RoleNum)

Table (AppNum, TableNum, TableName,)Primary Key: (AppNum, TableNum)

Foreign Key: (AppNum) REFERENCES [Application (AppNum)]

User (UserNum, UserName,UserPassword, UserCreatedDate, RoleNum)Primary Key: UserNum

Foreign Key 2: (RoleNum) REFERENCES [Roles (RoleNum)]


44/48


Page 44 of48

Database Description

Application

Application table consists of Application number (AppNum), Application name (AppName) andApplication date (AppDate).

AppNum - Application number is to record each application entry.AppNameApplication name is to differentiate each entry and their category.

AppDateApplication date is to keep track of the creating of data.

AttributesAttributes table consists of Attribute name (AttributeName).

AttributeNameEnsure each attribute has a name.

Constraint_AssociateConstraint has association of Boolean.AssociationIt has Boolean to identify if each application has any constraints.

Constraints

Constraint table consists of Constraint number (ConstraintNum), Constraint name (ConstraintName) and

Set size (SetSize).

ConstraintNumConstraint number is to uniquely identify constraint.

ConstraintNameConstraint name is to differentiate each constraint.

SetSizeSet size is to set lower bound.

RangeRange table consists of Range number (RangeNum ID), header name (Label), Minimum and Maximum

range define the label.

RangeNumIDRange number ID uniquely identify the different rangeLabelLabel indicates the header name

Minimum and MaximumThe value of the attribute

Report

Report table consist of Report name (ReportName), user name (UserName), application name(AppName), Report added date( ReportAddedDate)

Report_QueryReport query table consist of Query number(QueryNum), Report number(ReportNum), Report

name(ReportName), Report category(ReportCategory), Data (Data)


45/48


Page 45 of48

Report_Table

Report table consist of Report number(ReportNum), Report name(ReportName), Table name(TableName)

Role_AssociateRole associate table consist of Application number(AppNum), Table number(TableNum), Role

number(RoleNum), Association(Association)

RolesRoles table consists of Role name (RoleName) and a primary key of Role number (RoleNum ID)

RoleNameEach role has a name for the user.

LabelHeader name of the range of attributes.

MinimumDefine the lowest possible value of the attribute for particular table.MaximumDefine the highest possible value of the attribute for particular table.

Tables

A table consists of Table name with a primary key Table number (TableNum ID).TableNameEnsure each table has a name.

User

User table consists of User number (UserNum), User name (UserName), User password (UserPassword)and User created date (UserCreatedDate).

UserNumUser number is to allow different user having a unique number identification.UserNameEach user will have an identity.

UserPasswordUser will need to have password for authentication.

UserCreatedDateThe date must be recorded when each user is created.


46/48


Page 46 of48

Data Dictionary Database created in SQLite. Left column shows the tables in the database. Content of the

tables (user) information is in the main frame as shown:


47/48


Page 47 of48

One example of our Application Database (SIMStaff)

Relational Database DescriptionUniversity (University#, Name)

Primary Key: University#

Course (University#, Course#, Name)

Primary Key: Course#, University#

Foreign Key: University# ref [University University#]

Staff (Staff#, Name, DOB, Age, Gender, Address, Date_Join, PostName, Salary, Password)

Primary Key: Staff#


48/48


Created in SQLite

1.AppendixNIL

dss 12 s4 03 design specification

Documents